teilen
tweet
bluesky
masto
link
mail 
21. Oktober 2024
17 min.
Drucken
Korrektur
Kriterien für eine sichere Kommunikation
Ein sicheres Kommunikationssystem muss (mindestens) drei Eigenschaften aufweisen: Privatheit, Integrität und Authentizität. Alle drei müssen gegeben sein, ansonsten kann das System nicht als sicher gelten. Privatheit bedeutet, dass nur diejenigen den Inhalt der Kommunikation einsehen können, die dafür vorgesehen sind. Dritten soll das unmöglich sein. Dies ist das klassische Einsatzgebiet von Verschlüsselungsalgorithmen. Selbst, wenn die verwendeten Verschlüsselungsalgorithmen als zuverlässig eingeschätzt werden, hat Kommunikation einen “ausgefransten” Rand. So kann aus der Information, wer wann mit wem kommuniziert hat, womöglich auf den Inhalt geschlossen werden, ohne die Nachricht selbst zu entschlüsseln. Soziale Beziehungen können offen gelegt werden und sind für Angreifer:innen eventuell interessanter als die Nachrichteninhalte selbst.Integrität bedeutet, dass Nachrichten auf dem Weg von Sender:in zu Empfänger:in nicht verändert werden können, ohne dass es auffällt. Das schliesst das Verschwindenlassen von Nachrichten mit ein. Authentizität stellt sicher, dass die Nachrichten von der Quelle stammen, von der sie es behaupten. Niemand soll in der Lage sein, sich erfolgreich als jemand anderes ausgeben zu können. Authentizität schützt also u.a. vor einem Machine-in-the-Middle-Angriff und andersherum sind Machine-in-the-Middle-Angriffe primär Angriffe auf die Robustheit der Authentizität in einem Kommunikationssystem.
Anwender:innen stehen vor dem Problem, die Zusagen bzgl. Privatheit, Integrität und Authentizität eines Verschlüsselungssystems überprüfen zu wollen oder zumindest theoretisch zu können. Das geht nur, wenn die komplette Software mit allen ihren Bestandteilen auch einsehbar, also Open Source, ist. Zusätzlich muss sich dann auch noch jemand finden, der/die mit kompetentem Auge draufschaut, also ein Audit macht. Ohne regelmässige (externe) Audits kann einem System kein echtes Vertrauen entgegengebracht werden.
Ende-zu-Ende-Verschlüsselung vs. Transportwegverschlüsselung
Messenger sind mehr als nur die App auf dem Smartphone. Im Hintergrund sind üblicherweise eine Reihe von Servern beteiligt, welche die Nachrichten von Sender:in zur Empfänger:in übermitteln. Zumindest die/ der Empfänger:in muss in der Regel eine Kennung besitzen, die dauerhaft ist und sich nicht mit der Zeit verändert. Das schliesst bestimmte (technisch gegebene) Kennungen wie etwa die IP-Adresse aus, weil die sich im Laufe der Zeit ändern kann. Typischerweise “erfinden” Messengersysteme Kennungen (z.B. einen Nutzer:innennamen oder -nummer), und ein Endpunkt (z.B. eine App auf dem Smartphone) muss dem System gegenüber glaubhaft machen, dass er der zur Kennung zugehörige Endpunkt ist und deshalb berechtigt ist, Nachrichten für diese Kennung zu erhalten. Das bedingt eine Nutzer:innenverwaltung innerhalb des Messengersystems und hat damit unmittelbare Implikationen bezüglich einer anonymen Nutzung.Wenn zwischen Sender:in und Empfänger:in ein Server notwendig ist, muss mindestens die Empfangskennung für diesen Server lesbar sein, um die Nachrichten zuzustellen. Ausserdem gibt es Kommunikation mit dem oder den Servern des Messengersystems, die unabhängig von der Kommunikation mit einem anderen Endpunkt stattfinden soll. Beispiel dafür wäre ein auf dem Server hinterlegtes Adressbuch. Insbesondere dann, wenn ein:e Nutzer:in mehrere Apps für die gleiche “Identität” bzw. Kennung verwenden will z.B. eine App auf dem Smartphone und eine für den Desktop — und Nachrichten zwischen diesen Endpunkten synchronisiert werden sollen, damit die Endpunkte auf dem gleichen Stand sind, müssen Nachrichten auf dem Server "zwischenparken”, um später abgeholt zu werden. Um diese Verbindung zu schützen, also den Transportweg abzusichern (Transport Layer Security TLS), wird üblicherweise eine Verschlüsselungsebene zwischen Endpunkt und Server hergestellt.
Die Privatheit von Messengersystemen bedeutet, dass niemand Unberechtigtes die ausgetauschten Nachrichten mitlesen kann — weder auf beteiligten Servern, noch beim Transport der Nachrichten durch das Internet. Nachrichten müssen also“Ende-zu-Ende” (E2E) verschlüsselt sein, ein Entschlüsseln darf nur an den Endpunkten möglich sein. Das bedingt den Austausch von Schlüsseln zwischen den Endpunkten und führt damit zu dem Problem, deren Echtheit sicher stellen zu müssen sind die ausgetauschten Schlüssel die Originale oder sind sie auf dem Weg durch andere ersetzt worden?
Wenn kommunizierende davon ausgehen müssen, dass auf dem Weg, auf dem der Schlüsselaustausch stattfand, eine Ersetzung möglich war, dann können die Schlüssel auf diesem Weg nicht verifiziert werden, da auch diese Überprüfung manipuliert werden könnte. Es bleibt nur die Verwendung eines zweiten Weges, in der Hoffnung, dass der nicht auch kompromittiert wurde. Die Anforderungen an diesen zweiten Weg sind geringer, da der Schlüsselaustausch bereits stattgefunden hat es reicht, wenn sich darüber eine Prüfsumme vergleichen lässt.
Dieses Verfahren entspricht dem Abgleich von Fingerprints. In der Praxis ist das jedoch so umständlich, dass es häufig nicht stattfindet. Den Herstellern von Messengersystemen ist das bekannt, ausgetauschte Schlüssel lassen sich auch ohne Schlüsselverifikation nutzen teilweise auch ohne entsprechenden Hinweis auf die nicht mehr zu gewährleistende Authentizität der Nachrichten. Dieses Verfahren ist so verbreitet, dass es einen eigenen Namen bekommen hat: "Trust On First Usage” (TOFU). Die Annahme ist, dass ein erster Kontakt vermutlich noch nicht angegriffen wird, die Messengersoftware aber im Folgenden registriert, wenn Manipulationen stattfinden, und entsprechend warnt [3].
Perfect Forward Secrecy, Future Secrecy und Plausible Deniability
Sollte ein Angriff auf eine Kommunikation erfolgreich verlaufen sein, dann ist es wünschenswert, den verursachten Schaden so klein wie möglich zu halten. Die eingesetzten Verschlüsselungssysteme sollten einerseits sicherstellen, dass nach einem erfolgreichen Angriff nur Kommunikation ab diesem Zeitpunkt mitlesbar ist, dass also vorher mitgeschnittene Nachrichten nicht mit dem geraubten Schlüssel auch noch nachträglich entschlüsselt werden können (Perfect Forward Secrecy). Ein weiteres Ziel ist es, dass Angreifer:innen, die nur mitlesen und nicht aktiv Nachrichten manipulieren, höchstens so lange mitlesen können, bis beide Kommunikationspartner:innen je eine Nachricht geschickt haben. Diese kryptographische Eigenschaft, dass Mitlesen von Nachrichten nach einem Angriff in die Zukunft zu beschränken, wird auch Future Secrecy genannt.Ebenso ist es wünschenswert, dass die Autor:innenschaft einer Nachricht glaubhaft abgestritten werden kann (Plausible Deniability), jede:r sollte theoretisch in der Lage sein, eine bestimmte Nachricht verfasst zu haben. Das erste Verschlüsselungsverfahren, dass solche Eigenschaften mitbrachte, war OTR (Off The Record): ein Protokoll, bei dem sich der Schlüssel mit jeder Nachricht ändert. Dazu wird den Nachrichten Schlüsselmaterial beigefügt, aus dem der Schlüssel für die jeweils nächste Interaktion abgeleitet wird. Die Schwächen dieses Verfahrens sind zum Einen die Notwendigkeit, jeden Nachrichtenaustausch in der richtigen Reihenfolge empfangen zu müssen. Daher müssen beide Kommunikationspartner:innen gleichzeitig online sein um weiterhin gleiche Schlüssel zu verwenden ein Problem bei mobiler Kommunikation. Zum Zweiten kann eine Kommunikation nicht fliessend von einem Endpunkt auf den anderen übertragen werden, vom Smartphone zum Desktop zu wechseln, bedürfte einer Synchronisation der “flüchtigen Zwischenschlüssel”,
Um diese Nachteile aus der Welt zu schaffen, haben die Entwicklerinnen der Messaging-App "Signal" OTR weiterentwickelt. Die beiden Verfahren (genannt X3DH und Double Ratchet) sind nach Signal in weiteren Messengern nachgebaut - u.a. von WhatsApp und auch auf andere offene Protokolle (wie XMPP dort als “OMEMO”) übertragen worden.
Infrastruktur
Die Infrastruktur von Servern, die ein Messagersystem braucht, um zu funktionieren, lässt sich grob in drei Kategorien einordnen. Das bei populären Messengern verbreitetste Modell ist das des „Walled Garden“. Bei diesem Modell kommt alles aus einer Hand: App und Serverinfrastruktur. Die Infrastruktur ist oftmals auch abgesichert gegen alternative Apps - selbst, wenn nachvollziehbar wäre, wie das System funktioniert und die alternative Implementation von ihrer Funktionalität identisch wäre, würde sie nicht funktionieren.Das zweite Modell funktioniert auf der Ebene offener Protokolle. Die Methode der Kommunikation zwischen App und Infrastruktur ist öffentlich dokumentiert, eine Implementation erwünscht. Jeder und jede kann mit einem eigenen Server Teil der Infrastruktur werden, die Struktur ist verteilt föderiert. Dies ist das Prinzip, nach dem Email funktioniert. Wie bei Email auch, können bei diesem Modell ohne Probleme Anbieter oder Software gewechselt werden. Der Nachteil einer föderierten Infrastruktur ist die schwankende Qualität der einzelnen Bestandteile und die Unmöglichkeit, Bugfixes oder Erweiterungen zeitnah und in der ganzen Infrastruktur auszurollen - zu viele Parteien müssten da mitziehen.
Das dritte Modell fällt etwas aus der Rolle, weil hier keine (dezidierte) Infrastruktur existiert. Kommunikation findet direkt zwischen den Endgeräten ohne vermittelnde Server statt. Nachrichten werden „peer-to-peer” ausgetauscht. Beispiele hierfür sind Briar und Onionshare Chat.
Erwartete Features
Im Laufe der Zeit haben sich ein paar Features herauskristallisiert, die Nutzer:innen von einem Messengersystem erwarten. So soll die erfolgreiche Zustellung einer Nachricht nicht daran gekoppelt sein, dass die Empfangssseite ebenfalls online ist. Nachrichten müssen im Zweifel also “irgendwo” zwischengespeichert werden, um zu einem späteren Zeitpunkt zugestellt zu werden. Daran ist häufig auch noch die Rückmeldung an die Sendeseite geknüpft, die eine erfolgreiche Zustellung signalisiert. Hier offenbart sich ein Nachteil von peer-to-peer Lösungen, da nichts dazwischen ist, was zwischenspeichern könnte.Weiter ist das Hinzufügen mehrerer Endgeräte zu einem Account heute ein Standard-Feature, das die Kryptographie erheblich verkompliziert. Ein weiteres Feature ist der Gruppenchat, also die gleichzeitige Kommunikation von mehr als zwei Parteien. Soll diese Kommunikation verschlüsselt erfolgen, dann stellen sich Fragen der Verteilung der notwendigen Schlüssel. Scheidet eine Teilnehmer:in aus, muss darüber hinaus sichergestellt sein, dass verteilte Schlüssel nicht weiter gültig sind bzw. die ausgeschiedene Teilnehmer:in nicht weiter mitlesen kann. Die Umsetzung von verschlüsseltem Gruppenchat beinhaltet nicht-triviale Probleme für ein Messengersystem und ist eine relativ junge Anforderung bei der Entwicklung von Verschlüsselungstechnologie - historisch war die sichere Kommunikation zwischen genau zwei Parteien die Aufgabenstellung. Insofern ist es nicht überraschend, dass nicht alle Messengersysteme verschlüsselte Gruppenchats beherrschen bzw. nur unvollständig umsetzen.
Signal vs. XMPP+OTR/OMEMO vs. Matrix
Im Folgenden wollen wir Probleme von Signal, XMPP und Matrix benennen und gegeneinanderstellen.Signal
Signal ist ein Messenger, der angetreten ist, Ende-zu-Ende-Verschlüsselung (E2E) für die Massen zu realisieren. Die Entwickler:innen von Signal Open Whisper Systems haben X3DH und den Double Ratchet-Algorithmus entwickelt und verwenden darüber hinaus weitere Verfahren, um Metadaten zu minimieren. E2E-Verschlüsselung ist sowohl bei direkter Kommunikation zwischen zwei Teilnehmer:innen als auch in Gruppenchats gewährleistet. Für Signal gibt es auch einen Desktop-Client, der allerdings nur an einen Smartphone-Client oder inoffiziellen Command-Line-Client gekoppelt genutzt werden kann.Die Nutzer:innenkennung, die Signal gewählt hat, ist geerbt von der Nutzer:innenkennung der Endgeräte also der Telefonnummer der Smartphones. Die Betreiber:innen argumentieren mit der Nutzer:innenfreundlichkeit dieser Lösung, Nutzer:innen müssen sich keine neuen Kennungen für ihre Kommunikationspartner:innen merken (bzw. erst einmal herausfinden), sondern können diese einfach aus ihrem Telefonbuch entnehmen. Der Nachteil ist offensichtlich: Eine anonyme Nutzung von Signal ist zur Zeit nur durch Mehraufwand (anonyme SIM, nicht zuordenbares Endgerät) realisierbar. Mittlerweile versucht Signal durch nachträgliches hinzufügen von Aliasen dem Privacy-Problem entgegenzuwirken [4]. Die Registrierung ist nichtsdestotrotz an eine Telefonnummer geknüpft. Signal ist Open Source, der Code ist auf GitHub einsehbar und wird dort auch gepflegt.
Ob der dort sichtbare Code auch der ist, der zum Einsatz kommt, ist nicht nachvollziehbar. Kritisch ist, dass der Server-Code in der Vergangenheit oft ein ganzes Jahr lang nicht veröffentlicht worden ist, also dem produktiv eingesetzten Code weit hinterher hinkt. Signal ist ein Walled Garden, Nutzer:innen von Signal können via Signal nicht mit Nutzer:innen anderer Apps kommunizieren. Auch unterbindet Signal auf juristischem Weg, dass es Forks — also eigene Weiterentwicklungen, trotz Open Source gibt. Signal will damit der Zersplitterung des Ökosystems vorbeugen und einen gewissen Qualitätsstandard aufrecht zu erhalten. Im Laufe der Zeit hat Signal seinen Funktionsumfang erweitert: Mittlerweile sind auch Ende-zu-Ende-verschlüsselte (Sprach-)Telefonate und Videotelefonie möglich. Die Infrastruktur ist zentralisiert — nur Signal betreibt die nötige Serverinfrastruktur.
Die Hardware dafür ist angemietet: unter anderem bei Amazon, Google und Microsoft [5]. Dass Signal hier ausgerechnet Datenkraken für das Hosting gewählt hat, hinterlässt einen merkwürdigen Beigeschmack. Die Überlegung scheint zu sein, dass es bei einem Protokoll, das sowohl Ende-zu-Ende-verschlüsselt als auch Metadaten minimiert, egal ist, wo die Server laufen, da durch eine Observation derselben eine Angreifer:in nichts lernen kann. Hoffentlich stimmt das auch... Signal wird von einer Stiftung betrieben, die sich durch Spenden finanziert. Die Spender:innenliste wird nicht veröffentlicht. Zumindest die grossen Spender:innen sind aber bekannt. Unter anderem fliesst Geld der US-Regierung in das Projekt. Zumindest ist durch die Stiftung sichergestellt, dass der Betrieb nicht gewinnorientiert ist, die Motivation, Nutzer:innendaten in Geld zu wandeln, ist vermutlich gering.
Es gibt weitere Kritikpunkte, wie beispielsweise viele nicht nachvollziehbare Updates oder unklare Kooperationen, die wir aus Platzmangel nicht weiter ausführen wollen. Wir verweisen auf [6].
XMPP / Jabber
XMPP ist mittlerweile ein betagtes Protokoll, dessen Spezifikation Open Source ist. Gestartet ist XMPP mit einer rudimentären Funktionalität, die für Text-basierten Chat ausreicht. Im Laufe der Zeit sind zahllose Erweiterungen hinzugekommen, die teilweise server- oder clientseitig installiert und konfiguriert werden müssen. Für eine E2E-Verschlüsselung gibt es drei unterschiedliche Standards. Der erste basiert auf GPG und ist der Emailverschlüsselung nachempfunden, der zweite ist OTR, der dritte ist OMEMO, welches den Double Ratchet-Algorithmus und X3DH für den initialen Schlüsselaustausch implementiert. XMPP ist föderiert, es gibt eine Reihe von Serverimplementierungen, unterschiedliche Clients für diverse Plattformen und reichlich Anbieter:innen. Für die Erstellung eines Accounts sind nur ein Nutzer:innenname und Passwort nötig, was die Erstellung eines anonymen Accounts stark erleichtert.Das grundsätzliche Problem von XMPP ist, dass es als Klartextprotokoll gestartet ist. Welcher Funktionsumfang zur Verfügung steht bzw. aktiviert ist — insbesondere welche Arten von Verschlüsselung (E2E, TLS) hängt sowohl von der Konfiguration der beteiligten Clients als auch der beteiligten Server ab. Unkonfiguriert fällt XMPP immer in den Klartextmodus zurück. Das betrifft sowohl die Kommunikation zwischen Client und Server, als auch die Kommunikation der verschiedenen Server im föderierten Verbund. Insbesondere auf den zweiten Aspekt haben Nutzer:innen weder Einfluss noch Einsicht, sie können nur darauf vertrauen, das die Administrator:innen wissen, was sie tun. Eine weitere Folge dieses Protokolldesigns ist, dass Verschlüsselung oder Videotelefonie wie ein Aufsatz auf dem Klartextprotokoll funktioniert. Die Kommunikationsinhalte sind zwar verschlüsselt, laufen aber auf einem unverschlüsselten Sockel, mit der Folge, dass Metadaten im Klartext das Netz passieren. Das Problem lässt sich durch Transportverschlüsselung (TLS) entschärfen, die ist aber ebenfalls nur optional.
XMPP lässt sich sicher betreiben. Dafür müssen aber alle Beteiligten alles richtig machen, was keine gute Option ist, da Bedienfehler nicht ausgeschlossen werden können und im Zweifel erstmal nicht auffallen. Mit diesen Einschränkungen lässt sich eine brauchbare Kommunikation mit der Kombination Tails, XMPP,TLS, OTR, alle Teilnehmer:innen auf dem gleichen Server (um Server-zu-Server-Kommunikation auszuschliessen) realisieren, auch wenn der Aufwand relativ hoch ist.
Matrix
Matrix ist ebenso wie XMPP ein föderiertes Protokoll, das heisst, Nutzer:innen können sich selbst bei einem Server registrieren oder ihren eigenen betreiben. Die Registrierung ist anonym. Es werden lediglich ein Nutzer:innenname und ein Passwort benötigt. Im Gegensatz zu XMPP ist Matrix ein wesentlich moderneres Protokoll, das Features wie Videotelefonie, Gruppenchats und mehrere Geräte pro Nutzer:in unterstützt. Eines der Kernanliegen von Matrix ist Interoperabilität. Praktisch bedeutet das, dass Matrix sogenannte Bridges zur Verfügung stellt, die es Matrix-Nutzer:innen ermöglichen, mit den Nutzer:innen anderer Plattformen, beispielsweise Signal oder XMPP, so zu kommunizieren, als wären die externen Nutzer:innen direkt bei einem Matrix-Server registriert.Sowohl die Protokollspezifikationen als auch Clients und Server sind Open Source. Der bekannteste Client für Matrix heisst Element und läuft auf allen verbreiteten Plattformen, sogar im Webbrowser. Wir raten von der Verwendung des Browser-Clients allerdings dringend ab, da diese Ausführungsumgebung eine ganze Reihe an neuen Angriffsmöglichkeiten und Schwachstellen mit sich bringt [7].
Standardmässig werden Nachrichten in privaten Räumen Ende-zu-Ende-verschlüsselt. Dafür hat Matrix mit Olm und Megolm eigene Protokolle entwickelt. Olm wird zum Erstellen und Verwalten der Sessions zwischen zwei Geräten verwendet und ähnelt Signal, da es 3DH [8] und Double Ratchet verwendet. Weil Olm in grossen Gruppenchats nicht skaliert, wurde Megolm entwickelt. Mit diesem Protokoll werden die eigentlichen Nachrichten verschlüsselt (auch in Nicht-Gruppenchats). In Megolm werden Nachrichten signiert und es gibt statt Double nur eine symmetrische Ratchet. Daher gewährleistet Megolm auch nur Privatheit, Integrität, Authentizität und Perfect Forward Secrecy, aber nicht Future Secrecy oder glaubhafte Abstreitbarkeit, das heisst, eine einmal kompromittierte Konversation kann dauerhaft mitgelesen werden und die Urheberschaft der Nachrichten kann kryptographisch nachgewiesen werden.
Wer das jetzt zu kompliziert fand, befindet sich in guter Gesellschaft. Die Komplexität von Matrix ist vom Standpunkt der Sicherheit eines der grössten Probleme des Protokolls. Das hat in der Vergangenheit bereits zu diversen schwerwiegenden Sicherheitslücken geführt, die es Serveradmins etwa ermöglichten, alle Nachrichten mitzulesen oder sich als andere Nutzer:innen auszugeben [9]. Auch wenn die zu Grunde liegende Kryptographie vermeintlich stark ist, ist es nicht einfach, sie auch sicher anzuwenden in dem komplexen Setting aus serverseitigen Schlüssel-Backups, Gruppenchats, Session und Geräteverwaltung.
Neben diesen Problemen, die sowohl Implementierung als auch Spezifikation betreffen, gibt es noch weitere Punkte, auf die wir hinweisen möchten. Matrix erzeugt wie XMPP viele unverschlüsselte Metadaten, etwa wer wem wann Nachrichten geschrieben hat und welche Geräte wann registriert und verwendet wurden. Zudem werden Nachrichten abhängig von der Serverkonfiguration in der Regel aber für 30 Tage auf den Servern gespeichert, und zwar nicht nur auf dem eigenen, sondern auf denen aller Kommunikationspartner:innen. Bei der Verwendung von Bridges gibt es keine wirksame Ende-zu-Ende-Verschlüsselung. Dasselbe gilt für Chats in öffentlichen Räumen.
Vom Ansatz her ist es durchaus zu begrüssen, dass Matrix moderne Features hat, dabei standardmässig Ende-zu-Ende verschlüsselt, und Prinzipien wie Föderation und Interoperabilität hochhält. Angesichts der hohen Wahrscheinlichkeit weiterer Sicherheitslücken dieses komplexen und doch noch vergleichsweise jungen Protokolls sollten (potentielle) Nutzer:innen sich aber gut überlegen, ob Matrix die richtige Plattform für sicherheitskritische Kommunikation ist.
Dilemma: Keine gute Lösung
Wir haben viele Messenger nicht erwähnt und in diesem Text besprochen (wie z.B Telegram). Wir kennen keinen, der die Probleme, die wir an den drei diskutierten Messengern aufzeigen wollten, nicht auch hat. Messenger versprechen sichere Kommunikation, können dieses Versprechen aber nicht einhalten. Festplattenverschlüsselung, Transportwegverschlüsseltung (TLS) und Ende-zu-Ende-Verschlüssellung haben es Repressionsbehörden schwerer gemacht. Trotzdem gibt es Angriffe und keine absolute Sicherheit.Eine Erkenntnis aus dem Encrochat-Hack der französischen Behörden im Jahr 2020 ist, dass Repressionsorgane gerne den einfachen Weg gehen und sich nicht die Mühe machen, Verschlüsselungen zu knacken. Softwaremanipulationen in Absprache mit dem Provider ohne Wissen der Betreiber:innen hat die Behörden zu ihrem Ziel geführt. Eine Konsequenz daraus ist, Systeme so zu gestalten oder auszuwählen, dass die Infrastruktur unmassgeblich für Sicherheitsgarantien ist.
Nun kann mensch zu dem Schluss kommen, dass Server prinzipiell problematisch sind und deshalb eine Peer-to-Peer-Kommunikation favorisiert werden sollte. Diverse Messenger-Protokolle funktionieren serverlos und insbesondere auf dem Tor-Protokoll. Das Tor-Protokoll hat allerdings andere Sicherheitseigenschaften als gängige Messengerprotokolle. Diese Diskussion muss in einem separaten Text stattfinden.
Und neben vergleichbaren technischen Aspekten hat die Kommunikation über Messenger natürlich auch immer noch eine soziale Dimension. Ein sicherer und einfach handhabbarer Messenger bringt wenig, wenn ihn niemand aus dem zu erreichenden Umfeld nutzt. Ausserdem zeigt die Erfahrung, dass sich Messenger unterschiedlich auf das Kommunikationsverhalten auswirken. Ein Smartphone-Messenger wie Signal wird nahezu automatisch anders verwendet als ein Messenger, der nur unter Tails läuft und prägt damit die Gruppenkommunikation insgesamt. Auch eine genauere Betrachtung dieser Aspekte muss ebenfalls auf einen anderen Text verschoben werden.
Integrität und Topologie der Infrastruktur, Qualität der Verschlüsselungsalgorithmen, Umgang mit Metadaten, Business Modell und Erpressbarkeit sind zwar entscheidende Kriterien für die Beurteilung der Sicherheit eines Messengersystems. Beim Vergleich von Messengern nur nach diesen Kriterien gerät allerdings die Plattform, auf der der Messenger läuft, das Smartphone aus dem Blick. Selbst die besten Messenger setzen bei ihren Sicherheitsdesigns darauf, dass die Plattform integer und nicht kompromittiert ist. Davon kann leider nicht ausgegangen werden. Trojaner wie Pegasus oder FinFisher, ob privat eingesetzt oder mit hoheitlicher Segnung als Staatstrojaner, machen diese Grundannahme zunichte. Das Problem, digital sicher zu kommunizieren, bleibt komplex. Es gibt keine einfachen Lösungen.
