start | about | kontakt | alle tags | rss

gaenseblum.eu

skye gänseblums website

Wie man die Sicherheit verschlüsselter Kommunikation gewährleistet

05. December. 2023

Meine Chats sind schon verschlüsselt, reicht das?

Kurze Antwort: irgendwas zwischen „nein“ und „kommt drauf an“. Für die lange Antwort und Erklärungen, worauf genau es ankommt, ist der restliche Artikel da.

Hier klicken für PDF-Version

Click here for English version

Was dieser Artikel ist: ein Überblick über die Faktoren, die die Sicherheit von Nachrichtenaustausch im Internet beeinflussen. Er wendet sich an Personen, die lernen möchten, sich besser zu schützen. Das Ziel ist, ein allgemeines Verständnis für das Thema aufzubauen und Lesenden beizubringen, ihre eigenen Gefahrenmodelle auszuwerten und das richtige Werkzeug für ihre Anwendung auszuwählen. Im hinteren Teil gibt es eine zusammenfassende Liste von bewährten Methoden, welche nötig sind, um die Sicherheit verschlüsselter Kommunikation zu gewährleisten. Ziel dieses Artikel ist es, dir genug Hintergrundwissen zu vermitteln, dass du verstehst, welches Problem jeder der Punkte auf jener Liste löst.

Was dieser Artikel nicht ist: eine tiefgehende Erklärung der aktuellen Technologie, eine Liste empfohlener Dienste, oder in irgendeiner Form interessant für Leute, die mit diesem Kram täglich zu tun haben.

Struktur:

  1. Warum brauchen wir verschlüsselte Kommunikation?
  2. Gefahrenmodelle: Wogegen schützen wir uns?
  3. Grundwissen
    1. Verschlüsselung
    2. Der Weg von Nachrichten durch das Internet
    3. Arten von Attacken
  4. Von welchen Faktoren hängt die Sicherheit von verschlüsselter Kommunikation ab?
    1. Begrenzender Faktor 1: User
    2. Begrenzender Faktor 2: Das Gerät, das Betriebssystem, seine Konfiguration
    3. Begrenzender Faktor 3: Die App
    4. Begrenzender Faktor 4: Server
    5. Begrenzender Faktor 5: Die Verbindung
    6. Begrenzender Faktor 6: Schlüsselverifizierung (oder der Verzicht darauf)
    7. Begrenzender Faktor 7: Sonstige Daten
  5. Also was muss ich jetzt tun?
    1. Kurz und knapp als Liste
    2. PGP ja oder nein?
    3. Verschlüsselung ist nicht gleich Anonymität

1. Warum brauchen wir verschlüsselte Kommunikation?

Oder: Ich brauche das nicht, weil ich nichts Illegales mache!

In einer perfekten Welt hätten Personen, die nicht unmoralisch handeln, auch dann nichts zu befürchten, wenn sie ohne komplizierte Sicherheitsvorkehrungen kommunizieren. Leider leben wir nicht in einer perfekten Welt.

Tatsächlich müssen wir uns gegen vieles verteidigen: gegen Gefahrenquellen aus unserem Privatleben (Ex-Partner, gewalttätige Eltern und Ähnliches) oder aus unseren Berufsleben (der eigene Arbeitgeber sowie auch interessierte Parteien, die gerne Zugriff auf die Daten oder das Geld deiner Geschäftspartner oder Arbeitgeber hätten) und auch, ja, gegen Regierungen.

Das heißt nicht, dass dieser Artikel Menschen helfen soll, böse Dinge zu tun. Ganz im Gegenteil: Es besteht kein Zweifel, dass Regierungen oft böse handeln. Sie brechen nicht nur häufig ihre eigenen Gesetze, sondern die Gesetze selbst sind oft moralisch falsch. Überall auf der Welt gibt es so viele autoritäre Regierungen wie solche, die offenbar darauf hinarbeiten, es zu werden. Friedliche Demonstrant*innen, Journalist*innen, Schwangere, queere und trans Personen, Frauen, rassizifierte Menschen, kulturelle und religiöse Minderheiten sowie viele weitere Gruppen sind regelmäßig Opfer von ungerechter und unmoralischer, wenn auch oft legaler Unterdrückung. Der Schutz von Kommunikationsinhalten kann helfen, die Auswirkungen unterdrückerischer Maßnahmen zu verringern. Ich hoffe, dass klar ist, dass das Brechen ungerechter Gesetze aus ethischen Gründen erforderlich ist.

2. Gefahrenmodelle: Wogegen verteidigen wir uns?

Das Konzept von Gefahrenmodellen in der IT wirkt oft einschüchternd auf Personen, die nicht tief in diesem Thema drinstecken. Das liegt nicht daran, dass es schwierig zu verstehen ist, sondern daran, dass es üblicherweise dargestellt wird, indem die Namen von Werkzeugen, Protokollen und Programmen aufgelistet werden, von denen die meisten Leute noch nie was gehört haben.

Allgemeinverständlich ausgedrückt ist ein Gefahrenmodell einfach nur ein Konzept davon, gegen wen oder was du dich eigentlich verteidigen möchtest. Ich wette, dass dir die meisten dieser Punkte schon bekannt sind.

Du weißt wahrscheinlich längst, dass du dich gegen die folgenden Dinge schützen möchtest:

  • Automatisierte Attacken, ungerichtete Scam- / Spam- / Phishing-Versuche: Diese passieren oft in großer Menge zu geringem Preis. Wenn unter tausenden Zielen nur eins drauf reinfällt, hat es sich schon gelohnt.

  • Automatisierte Daten-Analyse zu Werbezwecken und zur Verhaltensbeeinflussung: Dies wird meistens eher als nervig denn als gefährlich angesehen, aber es ist auch das. Deine Daten informieren eine interessierte Partei im Zweifelsfalle über deine politische Einstellung, deinen medizinischen Status inklusive Schwangerschaft und Abtreibung, deinen Aufenthaltsort, deine Medienpräferenzen und viel mehr.

  • Automatisierte Daten-Analyse zur Feststellung tatsächlicher oder vermuteter Verstöße gegen Gesetze und Nutzungsbedingungen (Terms of Service, TOS), wie zum Beispiel Urheberrechtsverletzungen, Kinderpornografie, Terrorismus, Sexarbeit etc.: Manche dieser TOS und Gesetze sind moralisch falsch und müssen gebrochen werden. Manche davon rechtfertigen schlicht und einfach nicht die immense Verletzung der Privatsphäre, die mit dem Scannen und Auswerten privater Kommunikation einhergeht. Darüber hinaus gab es auch schon viele Fälle, in denen die automatische Feststellung eines vermuteten Verstoßes gegen Gesetze oder TOS das Leben unschuldiger Personen über den Haufen geworfen hat, ohne dass sie jemals das getan haben, was ihnen vorgeworfen wurde. Konzerne müssen sich niemandem gegenüber dafür rechtfertigen, wen sie auf welche Weise und aus welchen Gründen abstrafen.

  • Analyse von Verbindungen zwischen Invididuen, um die sozialen Strukturen von Bewegungen und Organisationen zu modellieren (Soziale Netzwerkanalyse): Diese Methode wird benutzt, um Führungsspitzen von Bewegungen oder informellen Organisationen zu identifizieren, damit diese isoliert und gezielt angegriffen werden können. Ziele sind beispielsweise Gewerkschaften, Menschenrechtsbewegungen oder jegliche Organisationen, die eine Regierung für eine Bedrohung hält, ungeachtet ihrer Legalität oder moralischen Richtigkeit.

  • Physikalischer oder Remote-Zugriff auf deine Geräte: Personen mit Zugriff auf ein Gerät können absichtlich oder versehentlich Spyware / Malware installieren oder Änderungen am System vornehmen. Uneingeladene interessierte Parteien können physikalischen Zugriff auf ein Gerät erhalten, indem sie in die Wohnung oder den Arbeitsplatz eindringen, oder im Fall staatlicher Autoritäten, indem sie das Gerät beschlagnahmen, beispielsweise im Rahmen einer Personenkontrolle oder Hausdurchsuchung.

  • Sniffing und/oder Manipulation privater Kommunikation durch uneingeladene Dritte: Der uneingeladene Dritte kann etwa dein örtlicher Stalker sein oder eine Person, die deinen Geschäftspartner gerne auf die ein oder andere Weise dazu bringen würde, einen größeren Geldbetrag auf ihr eigenes Konto zu überweisen. Es ist generell eine Person, die ein persönliches Interesse an ihrem Ziel hat, und die Attacken werden manuell ausgeführt. Die interessierte Partei kann Trojaner installieren, Exploits ausnutzen, Social Engineering anwenden, oder, abhängig von ihren Ressourcen, sogar physikalische Überwachungstechnologie einsetzen (ganz ehrlich, wenn es so weit kommt, haben die meisten von uns einfach verloren).

3. Grundwissen

3.1. Verschlüsselung

Wenn wir von modernen Verschlüsselungsmethoden und Ende-zu-Ende-Verschlüsselung sprechen, geht es so gut wie immer um Asymmetrische Verschlüsselung. Das bedeutet, das Schlüssel als Paare kommen, die aus einem öffentlichen und einem privaten Schlüssel bestehen.

Wenn Person A und Person B miteinander kommunizieren möchten, besitzen sie beide am Anfang nur ihr eigenes Set von öffentlichem und privatem Schlüssel.

A hat diese Schlüsel:

  • A-öffentlich
  • A-privat

B hat diese Schlüssel:

  • B-öffentlich
  • B-privat

Ein öffentlicher Schlüssel wird benutzt, um eine Nachricht zu verschlüsseln, und ein privater Schlüssel entschlüsselt sie wieder. Es gibt keine andere Möglichkeit, eine mit einem öffentlichen Schlüssel verschlüsselte Nachricht zu öffnen, als mit dem passenden privaten Schlüssel. (Da gibt es ein paar faszinierende Details, aber diese zu verstehen, ist für unseren Anwendungsfall nicht nötig. Wenn du mehr lernen willst, schlag nach, wie kryptografische Signaturen funktionieren.)

Um die Nachricht zu verschlüsseln, die A an B schicken will, muss A auf irgendeine Art den öffentlichen Schlüssel für B erhalten, und um antworden zu können, muss B den öffentlichen Schlüssel für A bekommen.

Nach dem anfänglichen Schlüsselaustausch sieht die Situation also so aus:

A hat diese Schlüsel:

  • A-öffentlich
  • A-privat
  • B-öffentlich

B hat diese Schlüssel:

  • B-öffentlich
  • B-privat
  • A-öffentlich

Der Vorteil asymmetrischer Verschlüsselung gegenüber symmetrischer Verschlüsselung, bei der derselbe Schlüssel zum Verschlüsseln und Öffnen benutzt wird, besteht darin, dass eine Drittpartei, die den Schlüsselaustausch abhört, die Nachrichten nicht entschlüsseln kann. Der öffentliche Schlüssel wird so genannt, weil er tatsächlich öffentlich ist: Auch wenn er uneingeladenen Dritten bekannt ist, ist die Sicherheit der Kommunikation gewährleistet.

Moderne Algorithmen mit mehreren gültigen Schlüsseln (siehe: double ratchet) sind erheblich komplexer, aber das Grundprinzip verstanden zu haben, bringt uns zu zwei sehr wichtigen grundlegenden Tatsachen:

  1. Bevor die Ende-zu-Ende-verschlüsselte Kommunikation losgeht, werden Schlüssel ausgetauscht. Dies ist immer der Fall, auch wenn es unsichtbar im Hintergrund passiert, und dass es oft unsichtbar passiert, ist ein Problem, über das wir später im Abschnitt über Schlüsselverifizierung reden werden.
  2. Wenn der Schlüssel die einzige Schutzebene darstellt (soll heißen, wenn du nicht für jede einzelne Nachricht, die du bekommst, zusätzlich noch ein Passwort eingeben musst), dann kann jede Person, die deinen privaten Schlüssel kennt, alle Nachrichten lesen.

3.2. Der Weg von Nachrichten durch das Internet

Dieser Abschnitt erklärt die grundlegenden Elemente von Nachrichtenaustauch im Internet sowie die potenziellen Angriffspunkte.

Betrachten wir das einfache Szenario: Person A benutzt Gerät 1, um eine Nachricht zu verschicken, die von Gerät 2 empfangen und von Person B gelesen wird.

Person A ⇒ Gerät 1 ⇒ Übertragung ⇒ Gerät 2 ⇒ Person B

Wie viele mögliche Angriffspunkte siehst du in diesem Diagramm? Ich geb dir eine Minute, um drüber nachzudenken. Nein, ehrlich. Wie viele Angriffspunkte sind in diesem Diagramm?

Hast du drüber nachgedacht? Hast du eine Antwort? Die Antwort ist sieben.

  • Die Nachricht kann während der Übertragung aufgefangen werden.
  • Gerät 1 und Gerät 2 können kompromittiert sein.
  • Person A und Person B auch.
  • Ein oft vergessener Risikofaktor ist die Umgebung, in der Person A und B sich befinden, wo sie absichtlich oder versehentlich von Dritten beobachtet werden können.

Wenn diese einfache Darstellung noch überschaubar wirkt, dann tut es mir sehr leid, dir zu sagen, dass es schlimmer wird, denn sie wäre nur dann wahrheitsgetreu, wenn A und B direkt miteinander kommunizieren würden, zum Beispiel, wenn sie die Nachricht über Bluetooth schicken würden. Das Internet ist alles andere als direkt.

Der erste zusätzliche Knoten, den wir in der Mitte einfügen müssen, ist der Server. Praktisch jeder Online-Dienst, den wir benutzen, läuft über einen Server, der die Nachricht empfängt und zu ihrem Empfänger weiterleitet. Dies stimmt im Falle eines zentralisierten Dienstes wie zum Beispiel Telegram oder Signal.

Jetzt sieht unser kleines Diagramm so aus:

Person A ⇒ Gerät 1 ⇒ Übertragung ⇒ Server ⇒ Übertragung ⇒ Gerät 2 ⇒ Person B

Im Fall eines dezentralisierten Dienstes wie E-Mail oder Matrix, wo sich mehrere Server miteinander austauschen und A und B ihre Konten auf verschiedenen Seiten haben, sieht das ein bisschen schlimmer aus:

Person A ⇒ Gerät 1 ⇒ Übertragung ⇒ Server 1 ⇒ Übertragung ⇒ Server 2 ⇒ Übertragung ⇒ Gerät 2 ⇒ Person B

Aber, ich hab dich vorgewarnt, es wird noch schlimmer. Schauen wir uns den Teil mit der Übertragung genauer an. Ziemlich unkompliziert, oder nicht? Deine Bits wandern durch die Luft oder durch Kabel und kommen an ihrem Ziel an… Tun sie halt nicht, zumindest nicht direkt. Der Begriff der „Übertragung“ ist eine Abkürzung für alles, was zwischendrin passiert, also lasst uns die Abkürzung mal auflösen und die Realität betrachten.

Nimm dein Heimnetz als Beispiel: Da steckt ein Router zwischen dir und dem Internet, der jedes einzelne Bit, das zu sendest oder empfängst, annimmt und weiterleitet. Und zwischen dir und deinem Server sind noch ein Dutzend weitere Router, deren einzige Aufgabe ist, diese Bits in das richtige Kabel zu schubsen… Oder, in manchen Fällen, diese Bits zu speichern und zu analysieren und ihre Absender zu überwachen.

Jetzt sieht unser hübsches kleines Szenario vom Senden einer Nachricht ungefähr so aus:

Person A ⇒ Gerät 1 ⇒ Router ⇒ Router ⇒ Router ⇒ Server 1 ⇒ Router ⇒ Router ⇒ Router ⇒ Server 2 ⇒ Router ⇒ Router ⇒ Router ⇒ Gerät 2 ⇒ Person B

Was für ein Chaos. Und das ist immer noch eine krasse Vereinfachung — in Wirklichkeit sind da viel mehr Schritte dazwischen. Du kannst es einfach austesten, indem du ein traceroute-Programm installierst und is mal auf verschiedene Domains anwendest, die du gerne besuchst. Du wirst üblicherweise dutzende Hops sehen, und jeder davon ist vom Prinzip her ein Computer, der seinen eigenen Code ausführt und mit den Daten, die du sendest, machen kann, was er will. Wenn deine Daten nicht verschlüsselt sind, heißt das auch, dass jeder dieser Knoten ihren Inhalt kennt. Wenn du also zum Beispiel eine unverschlüsselte E-Mail über eine ungesicherte Verbindung verschickst, dann kennt jetzt theoretisch jede einzelne der Maschinen, die sie weiterschicken, den Inhalt der E-Mail. Wenn du ein Passwort über ungesichertes HTTP verschickst, kennt jede davon dein Passwort. Wenn du eine ungesicherte HTTP-Website besuchst, kann jeder dieser Knoten dir eine falsche Website auftischen. Bevor SSL/TLS zum alltäglichen Standard gemacht wurden, haben wir fast alles unverschlüsselt geschickt. Es ist unklar, wie wir diese Phase des Internets überlebt haben. Wir werden mehr über TLS und Zertifikate sprechen, wenn wir zur Verbindung als limitierender Faktor kommen. An dieser Stelle sagen wir einfach mal: Verschlüsselung ist das einzige, das verhindert, dass deine komplette Online-Kommunikation in 100% der Fälle von einem Dutzend kleiner Spione abgehört wird.

Eine grundlegende Vorstellung davon zu haben, wie Nachrichten ihren Weg durch das Internet finden, macht uns eine wichtige Sache klar: Es gibt dutzende potenzieller Risikofaktoren zwischen Sender*in und Empfänger*in, und manche davon sind sozialer Natur.

3.3. Arten von Attacken

Um zu verstehen, wogegen wir uns verteidigen, müssen wir eine grundlegende Vorstellung davon haben, auf welche Weise unsere Daten ausgespäht werden können. Mit der Beschreibung dieser Methoden könnte man ein ganzes Buch füllen, daher werden hier nur einige ausgewählte Techniken sehr grob beschrieben.

  • Spyware: Spyware ist eine Form von Malware, die auf einem System installiert wird. Viele Spyware wird wie ganz normale Software verkauft und lässt sich sogar über App Stores installieren. Sie wird oft beworben, um z.B. die Aktivitäten von Kindern oder Mitarbeiter*innen in einem Unternehmen zu überwachen. Viele der Anwendungen, die auf Arbeitsgeräten installiert werden, enthalten Spyware. Spyware kann z.B. einen Keylogger beinhalten, sie kann Online-Aktivitäten verfolgen, Bildschirmaufnahmen machen, Standortdaten aufzeichnen, Kameras und Mikrofone verwenden und all das an einen ausgewählten Empfänger senden, ohne dass die überwachte Person davon etwas mitbekommt. In vielen Fällen wird installierte Spyware entweder versteckt oder sieht auf den ersten Blick wie unverfängliche Software aus, z.B. wie eine Taschenrechner-App.
  • Man In The Middle: Dies ist eine Form von Angriff, die nicht auf dem eigenen Gerät stattfindet, sondern irgendwo zwischen dem Sender und dem Empfänger. Eine interessierte Partei fängt die Kommunikation zwischen A und B ab und leitet sie entweder unverfälscht oder mit gewissen Änderungen weiter. Für A und B sieht es so aus, als würden sie miteinander reden. Wenn die Kommunikation nicht verändert wird, fällt A und B unter Umständen niemals auf, dass sie abgehört werden. Ein Beispiel für eine Manipulation wäre, wenn ein Man In The Middle eine E-Mail mit Kontodaten abfängt, die Kontodaten auf die eigenen ändert, und die Mail dann weitersendet.
  • Änderung von Browser-, App- oder Systemeinstellungen: Dies kann entweder manuell passieren oder beispielsweise durch eine Anwendung, die nur ein einziges Mal ausgeführt werden muss, um permanente Änderungen vorzunehmen. Diese Änderungen können z.B. zusätzliche Benutzerkonten sein, die Installation von TLS-Root-Zertifikaten (dazu später mehr) oder das Aktivieren von Diensten. Diese Dinge können einer interessierten Partei Zugriff auf private Daten ermöglichen.
  • Diebstahl von Login-Daten: Wenn der interessierten Partei ein Passwort bekannt ist, kann sie dieses nutzen, um sich einzuloggen und Daten zu kopieren. Besonders Systemkonten oder beispielsweise das Apple-, Microsoft- oder Google-Konto beinhalten oft extrem viele sehr private Daten, die jeder Person zugänglich sind, die das Passwort dafür besitzt. Besonders einfach ist der Diebstahl von Login-Daten, wenn ein unsicheres Passwort verwendet wird, wenn dasselbe Passwort mehrmals wiederverwendet wird, wenn man bei der Passworteingabe beobachtet wird, oder wenn man auf einem unsicheren, mit Spyware ausgestatteten System seine Daten eingibt. Multi-Faktor-Authentisierung kann helfen, dieses Risiko zu minimieren.
  • Social Engineering und Phishing: Es gibt viele Methoden, jemanden dazu zu bringen, Spyware zu installieren, Änderungen kritischer Einstellungen vorzunehmen oder Login-Daten auf gefälschten Seiten einzugeben. Manche davon sind so ausgeklügelt, dass sie selbst für Profis schwer zu identifizieren sind.

4. Von welchen Faktoren hängt die Sicherheit von verschlüsselter Kommunikation ab?

Mit dem Wissen aus dem letzten Abschnitt können wir die Faktoren identifizieren, die unseren Schutz gegen die Bedrohungen aus unserem Gefahrenmodell begrezen. Dies hilft uns, zu verstehen, welchen Schutz wir brauchen und warum.

4.1. Begrenzender Faktor 1: User

Dein eigenes Verhalten beeinflusst deine Sicherheit.

Wie sicher sind deine Passwörter? Trägst du sie in ein Notizbuch ein? Wer hat Zugang zu diesem Notizbuch? Speicherst du sie in einem Passwortmanager? Wie sicher ist dein Passwortmanager?

Welchen Netzwerken vertraust du? Benutzt du unsichere Verbindungen?

Hältst du dein System auf dem aktuellen Stand? Installierst du irgendwelche Software und hoffst auf das Beste?

Welchen Geräten vertraust du? Benutzt du einen Computer, zu dem andere Personen ebenfalls Zugang haben? Wer sind diese Personen?

Gibst du anderen Personen deine Daten? Speicherst du manche deiner Daten an unsicheren Orten? Speicherst du Backups in unverschlüsselten Cloud-Diensten?

Kannst du Phishing-Attacken identifizieren? Benutzt du Multi-Faktor-Authentisierung? Steckst du irgendwelche USB-Sticks von fremden Leuten einfach in dein Gerät? Lässt du irgendwelche Leute dein Gerät benutzen?

Verifizierst du Schlüssel?

Über die meisten dieser Fragen werden wir noch detaillierter sprechen. Die wichtigste Feststellung hier ist, dass deine digitale Sicherheit vor allem vor dir selbst abhängt. Niemand anders wird es für dich tun, und auch ein relativ solides System kann keine Sicherheit gewährleisten, wenn es nicht korrekt verwendet wird.

4.2. Begrenzender Faktor 2: Das Gerät, das Betriebssystem, seine Konfiguration

Sämtliche Daten, auf die du selbst zugreifen kannst, ohne ein Passwort eingeben zu müssen, können von jeder Person mit physikalischem Zugang zu deinem Gerät kopiert und verändert werden. Face ID und Fingerabdrucksensoren sind bestenfalls eine Kindersicherung und bieten keine Sicherheit. Ein Foto deines Gesichts kann ausreichen, um Face ID auszutricksen, und dein Fingerabdruck kann direkt vom demselben Gerät abgenommen werden, das damit abgesichert ist. Es gibt keine Alternative zu guten Passwörtern. Muster und PINs zählen als Passwörter, aber sie müssen sehr lang und zufällig sein, um das gleiche Level von Sicherheit wie ein starkes Passwort zu liefern.

Allerdings wird dich auch ein starkes Login-Password nicht retten, wenn deine Daten auf dem Laufwerk selbst nicht verschlüsselt sind. Warum nicht?

Stell dir vor, du hast einen USB-Stick an deinen Laptop angeschlossen. Wenn dein Bildschirm gesperrt ist, kann nur eine Person, die dein Passwort kennt, sich einloggen und auf die Daten auf dem Stick zugreifen. Aber wenn der Stick nicht verschlüsselt ist, kann sie ihn natürlich einfach rausziehen, in ihren eigenen Laptop stecken und all deine Daten kopieren oder verändern. Nun führe dir vor Augen, dass das Laufwerk in deinem Laptop (oder Computer, oder in deinem Handy) sich nur insofern von diesem USB-Stick unterscheidet, dass es etwas mehr Arbeit ist, es auszubauen.

Aus diesem Grund brauchen wir Laufwerk-Verschlüsselung, um zu gewährleisten, dass die Daten im Ruhezustand gesichert sind („secure at rest“): Wenn das Gerät ausgeschaltet oder das Laufwerk nicht verbunden ist, gibt es keine Möglichkeit, an die Daten auf dem Laufwerk zu gelangen, ohne das Passwort und/oder die Schlüssel-Datei zu besitzen (welches davon du verwenden solltest, hängt davon ab, ob du erwartest, dass ein Angreifer eine Schlüssel-Datei auf einem separaten Gerät finden und benutzen kann oder in der Lage ist, an dein Passwort zu kommen).

Wir nennen es „secure at rest“, weil die Daten im aktiven Zustand nicht gesichert sind. Solange das Gerät in Verwendung ist, befindet sich der Schlüssel im Arbeitsspeicher der Maschine. Wer Zugriff auf das Gerät hat, kann den Arbeitsspeicher auslesen (z.B. mittels Kaltstartattacke) und so an den Schlüssel gelangen. Laufwerk-Verschlüsselung ohne Login-Sicherung ist ebenso nutzlos wie Login-Sicherung ohne Laufwerk-Verschlüsselung. Also, ja, du brauchst wirklich beides: Ein starkes Passwort, dass du jedes Mal eingibst, wenn du auf das Gerät zugreifst (ja, sogar dein Handy) und ein starkes Passwort, um die eigentlichen Daten auf deinem Laufwerk zu verschlüsseln.

Diese beiden Dinge zu haben, macht dein Gerät nicht automatisch sicher: Malware, die auf dem System läuft, kann immer noch auf deine Daten zugreifen; ebenso bösartige Hardware wie z.B. Hardware-Keylogger, die einfach jeden einzelnen Tastenanschlag registrieren und aufzeichnen.

Das bringt uns zu einer weiteren Schlussfolgerung: Sobald eine nicht vertrauenswürdige Partei physikalischen Zugriff auf dein Gerät hatte, kannst du sowohl die Hardware als auch die Software nur noch als verbrannt betrachten. Du kannst ggf. deine wertvollen Dateien vom Laufwerk retten, aber unter keinen Umständen solltest du das Gerät einschalten und deine Passwörter eingeben, um dies zu tun. Jede ausführbare Datei auf dem Gerät, inklusive seinem UEFI und Bootloader, ist genauso gefährlich wie die möglicherweise modifizierte Hardware.

Im Falle normaler Benutzung gibt es bewährte Praktiken, die befolgt werden sollten, um auf deinem Betriebssystem eine sichere Umgebung zu gewährleisten:

  • Du solltest keine Software installieren oder ausführen, der du nicht vertraust, da es Malware/Spyware sein könnte und Änderungen vornehmen könnte, die bleiben, auch wenn du die Software deinstallierst.
  • Nimm keine Änderungen an deinem System oder Browser vor, die du nicht verstehst, da du Einstellungen ändern könntest, die deine Sicherheit negativ beeinflussen.
  • Installiere Aktualisierungen für dein System und deine Software, da Sicherheitslücken darin nur durch Updates geschlossen werden können. (Als Anmerkung: Es kann auch vorkommen, dass bösartige Aktualisierungen eingeschleust werden. In Umgebungen mit sehr hohem Risiko werden daher automatische Updates ggf. deaktiviert und nur nach Überprüfung eingespielt. Für den Alltag sind automatische Updates eine gute Lösung.)
  • Lass keine unnötigen Dienste laufen. Alles, das mit der Außenwelt kommuniziert, ist eine potentielle Quelle für Probleme.
  • Deinstalliere Software, die du nicht brauchst. Was nicht da ist, kann auch keine Probleme verursachen.
  • Wenn irgendwas sich falsch anfühlt oder du Grund zu der Annahme hast, dass dein System kompromittiert wurde, musst du eine vollständige Neuinstallation vornehmen / auf Werkseinstellungen zurücksetzen. Du kannst Dateien backuppen (Bilder, Dokumente, Browser-Lesezeichen etc.), aber du solltest keine Einstellungen oder Konfigurationsdateien übernehmen, die du nicht händisch auf Korrektheit überprüfen kannst, da sie Einstellungen beinhalten könnten, die Hintertüren öffnen.
  • Wenn dein System einmal kompromittiert wurde, musst du davon ausgehen, dass alles, was auf deinem Bildschirm angezeigt wurde, gesehen wurde, dass jede deiner Dateien geöffnet wurde und dass jeder Tastenanschlag aufgezeichnet wurde. Das bedeutet auch, dass du sämtliche deiner Passwörter ändern musst (und dass es sinnlos ist, dies auf dem kompromittierten System zu tun).
  • Wenn dein Arbeitgeber verlangt, dass du bestimmte Software installierst oder Änderungen an deinem System vornimmst, solltest du es vermeiden, dasselbe System für die Arbeit und für private Nutzung einzusetzen, da diese Anwendungen oft Spyware enthalten und die Änderungen es ermöglichen könnten, deine Kommunikation abzuhören.

4.3. Begrenzender Faktor 3: Die App

Wenn du verschlüsselte Nachrichten sendest, benutzt du mit ziemlicher Sicherheit eine Anwendung, um das zu tun. Diese Anwendung läuft entweder im Browser oder direkt auf deinem Gerät. Im beiden Fällen musst du der Anwendung vertrauen können:

  • Du musst darauf vertrauen, dass die App, die du heruntergeladen hast, auf ihrem Weg nicht manipuliert wurde, und dass es wirklich die richtige App ist und kein bösartiger Doppelgänger. App Store und Google Play sind ziemlich gut darin, Ersteres zu gewährleisten, und unterirdisch bei Letzterem. Wenn du einen Paketmanager unter Linux/USB benutzt, kannst du der Echtheit der Software nur dann gewiss sein, wenn die Pakete Signaturen besitzen und diese Signaturen geprüft werden. Nicht jedes Paketmanagement unterstützt Signaturen. Wenn du die Software direkt über eine Website herunterlädtst, musst du sicher sein, dass die Website die richtige ist.
  • Auch wenn du die korrekte App hast, heißt das nicht zwangsweise, dass du geschützt bist. Die App kann Sicherheitslücken haben, oder der Anbieter kann absichtlich Hintertüren eingebaut haben, um seine Benutzer*innen ausspionieren zu können. Unter Umständen haben Regierungen diese Hintertüren angefragt oder sie verpflichtend gemacht. Die App könnte sogar so weit gehen, dass sie proaktiv deine Nachrichten scannt, um personalisierte Werbung betreiben zu können, oder um gesetzlichen Verpflichtungen zu entsprechen (Chatkontrolle). An diesen Punkten wird die Stärke von Open-Source-Software klar: Leute, denen Sicherheit am Herzen liegt, lesen den Code und schlagen Alarm, wenn sie Hintertüren oder Überwachungsroutinen entdecken.
  • Ist die Verschlüsselung echte Ende-zu-Ende-Verschlüsselung? Werden die Daten wirklich ausschließlich auf deinem Gerät entschlüsselt? Wenn du gleichzeitig dein Gerät und dein Passwort verlierst, gibt es noch irgendeine Möglichkeit, an deine Daten zu kommen? Wenn das der Fall ist, ist dieser Punkt nicht erfüllt und die Verschlüsselung ist nicht sicher.

4.4. Begrenzender Faktor 4: Server

Die Server-Konfiguration ist für Benutzer*innen üblicherweise nicht einsehbar. Dies stellt ein Problem dar, da Server Zugang zu einer erheblichen Datenmenge haben, sogar im Falle von echter Ende-zu-Ende-Verschlüsselung. Dies spricht für die Verwendung dezentralisierter Dienste, da hierbei ein Server ausgewählt werden kann, dessen Betreiber*in du zutraust, sich um deine Privatsphäre zu kümmern und dies technisch umzusetzen.

Wenn du einen nicht quelloffenen Dienst benutzt, ist es schwierig, festzustellen, ob der Server an irgendeiner Stelle deinen Schlüssel erhält, oder ob er die Möglichkeit besitzt, deine Daten zu entschlüsseln und zu analysieren, was effektiv das Konzept von Ende-zu-Ende-Verschlüsselung aushebeln würde.

Web Apps (das sind Anwendungen, die du in einem Browser aufrufst, wie beispielsweise Telegram oder Whatsapp auf deinem Computer oder das Element Web-Interface): Da die Anwendung nicht lokal installiert ist, entspricht jeder Besuch der Website einem Download einer neuen Version der App. Wenn der Server kompromittiert ist, kann er dir eine gefälschte Website senden und all deine Daten klauen.

Auch, wenn deine Nachrichten vollständig verschlüsselt sind, nicht vom Server ausgelesen werden können, und der Server sicher ist, kann das Speichern unnötiger zusätzlicher Daten dich in große Schwierigkeiten bringen (darüber reden wir im Abschnitt über die sonstigen Daten).

4.5. Begrenzender Faktor 5: Die Verbindung

Wie schon erwähnt, passieren Nachrichten auf ihrem Weg durch das Internet viele verschiedene Router. Einer davon ist üblicherweise unter deiner eigenen Kontrolle, und das ist der bunt blinkende Kasten, der an die Telefondose angeschlossen ist. Wenn auf deinem Router Malware läuft, wirst du keinen Spaß daran haben. Router müssen so gewissenhaft gepflegt werden wie jedes andere Gerät: Sichere Passwörter, regelmäßige Updates, und Zurücksetzen gebraucht organisierter Geräte.

Heutzutage wird die überwältigende Mehrheit der Daten im Internet mit TLS verschlüsselt. Dadurch können auch Daten, die kein eigenes kryptografisches Layer besitzen, nicht ohne Weiteres von Dritten ausgespäht oder manipuliert werden, auch nicht von den Routern, die sie passieren. TLS ist ziemlich sicher insofern, dass es von außen nicht einfach geknackt werden kann und man entweder Zugang zum Server oder zum Client haben muss, um die übertragenen Daten auszulesen oder zu manipulieren.

Um zu verstehen, in welchen Fällen wir TLS vertrauen können und in welchen nicht, müssen wir ein bisschen darüber wissen, wie TLS funktioniert.

Eine mit TLS gesicherte Verbindung wird aufgebaut, indem ein TLS Handshake durchgeführt wird. Dieser Handshake dient dazu, Sitzungsschlüssel auszuhandeln, die symmetrische Verschlüsselung verwenden, da diese weniger Rechenleistung benötigt und dadurch für den Transfer großer Datenmengen besser geeignet ist. Um zu verhindern, dass uneingeladene Dritte, welche die Verbindung beobachten, die Sitzungsschlüssel erhalten, werden die Nachrichten, in denen die Schlüssel ausgehandelt werden, mit einem anderen Algorithmus verschlüsselt.

Jeder TLS-Server besitzt ein Paar aus öffentlichem und privatem Schlüssel. Die Handshake-Nachricht, die vom Client gesendet wird, ist mit dem öffentlichen Schlüssel des Servers verschlüsselt, und nur der Server kann diese Nachricht öffnen, da (hoffentlich) niemand anders den privaten Schlüssel des Servers besitzt.

Die größte Herausforderung bei asymmetrischer Verschlüsselung ist die Verifizierung der Identität des Kommunikationspartners: Du musst dir absolut sicher sein, dass der Schlüssel, den du erhalten hast, der Person gehört, mit der du reden möchtest. Im Falle von TLS wird diese Verifizierung wird durch Zertifikate gewährleistet. Es gibt eine begrenzte Anzahl von Zertifizierungsstellen (Certificate Authority, CA), welche sogenannte Root-Zertifikate besitzen. Durch eine „Vertrauenskette“ werden diese Root-Zertifikate benutzt, um Zwischenzertifikate zu signieren, mit welchen dann wiederum die eigentlichen Server-Zertifikate signiert werden. Diese Server-Zertifikate beinhalten unter anderem den öffentlichen Schlüssel des Servers. Wenn der Server ein Zertifikat besitzt, das dein Betriebssystem oder Browser als gültig akzeptieren, dann bedeutet das letztendlich, dass eine der Zertifizierungsstellen, deren Root-Zertifikate auf deinem Gerät gespeichert sind (diese werden als Teil von Betriebssystem oder Browser ausgeliefert), verifiziert hat, dass der öffentliche Schlüssel, den du für die Verschlüsselung benutzt, tatsächlich zu dem Server gehört, mit dem du dich verbinden möchtest.

Hieraus ergibt sich, dass Root-Zertifikate der Punkt sind, an dem TLS kaputtgehen kann. Wenn ein bösartiges Zertifikat auf deinem System als vertrauenswürdig markiert wurde, kann dieses bösartige Root-Zertifikat verwendet werden, um bösartige Server-Zertifikate zu signieren, denen dein Gerät dann automatisch vertraut. Dies ermöglicht es der bösartig handelnden Partei, Man-In-The-Middle-Angriffe durchzuführen.

Es ist möglich, manuell zusätzliche Root-Zertifikate zu installieren. Du könntest dein eigenes Root-Zertifikat erstellen, and alle, die es auf ihren System als vertrauenswürdiges Zertifikat speichern, würden automatisch alle Zertifikate als vertrauenswürdig ansehen, die du signiert hast. In der Tat ist das etwas, das viele Arbeitgeber tun.

Diese Fakten summieren sich zu folgender Beschränkung:

TLS ist nur dann sicher, wenn 1. keine bösartigen Zertifikate installiert wurden (z.B. durch Unwissenheit, Vorschrift eines Arbeitgebers, Malware, oder unerwünschten Zugriff auf das Gerät) und 2. die Zertifizierungsstellen selbst vertrauenswürdig sind.

Da die großen Zertifizierungsstellen der Kontrolle von Großkonzernen unterliegen, von denen die meisten ihren Sitz in den USA haben, bedeutet Vertrauen in TLS nicht nur Vertrauen in dein Gerät und die Software, die du benutzt, sondern auch in die Konzerne, welche die TLS-Root-Zertifikate kontrollieren sowie in die Regierungen der Länder, in denen sie sich befinden. Deshalb ist eine zusätzliche kryptografische Ebene in Form von Ende-zu-Ende-Verschlüsselung nötig, um empfindliche Informationen zu schützen.

Wenn dein persönliches Gefahrenmodell TLS als nicht vertrauenswürdig definiert, oder falls es Regierungen gelingt, ihre eigenen Root-Zertifikate als vertrauenswürdig zu markieren, sind Web-Apps keine sichere Wahl mehr für die Kommunikation, auch dann nicht, wenn sie ihre eigene Verschlüsselung besitzen (Matrix, Telegram, …), da ein Man In The Middle einfach eine falsche Website auftischen kann, die deine Daten ausliest oder verändert. Mit eigenständigen Programmen lässt sich dies weniger leicht bewerkstelligen; viele Apps auf Mobilgeräten sind allerdings in ihrem Inneren auch nur ein Browser, sodass das Problem möglicherweise dennoch besteht.

Die Verwendung von VPN oder Tor-Browser macht deine Verbindung nicht sicherer. Was sie tun, ist deinen Aufenthaltsort zu verstecken, indem sie deine IP-Adresse verschleiern. Dein Browser-Fingerprint kann dich immer noch identifizieren und es gibt keine zusätzliche Verschlüsselung, um den Inhalt deiner Nachrichten zu schützen. Nur Tor Onion Services besitzen eine eigene kryptografische Ebene und verlassen sich zur Absicherung nicht allein auf TLS.

4.6. Begrenzender Faktor 6: Schlüsselverifizierung (oder der Verzicht darauf)

Die meisten Messenger benutzen heutzutage Ende-zu-Ende-Verschlüsselung durch asymmetrische Algorithmen. Wenn du einen neuen Chat öffnest, werden die öffentlichen Schlüssel automatisch ausgetauscht. Du beginnst deine Kommunikation und vertraust daraufh, dass die Schlüssel korrekt ausgetauscht wurden, dass kein Man In The Middle einen falschen Schlüssel an beide Enden serviert hat, um eure Kommunikation belauschen oder manipulieren zu können.

Wenn deine Kommunikation privat ist oder du Grund zu der Annahme hast, dass dich jemand anzugreifen versucht, solltest du nicht darauf vertrauen.

Anwendungen mit einem Fokus auf Sicherheit besitzen immer eine Möglichkeit, die Schlüssel anzeigen zu lassen, die in einer Sitzung verwendet werden. Diese werden nicht unbedingt „Schlüssel“ genannt; unter Umständen heißen sie „Sicherheitsnummer“ oder werden durch Emoji dargestellt, weshalb es nicht gerade leicht ist, hierfür eine universelle Beschreibung zu liefern. Im Zweifelsfalle kannst du eine Suchmaschine fragen, wie man in deiner jeweiligen App die Schlüssel verifiziert. (Technisch gesehen ist das, was ihr da vergleicht, nicht der eigentliche Schlüssel, der zum Verschlüsseln der Nachrichten benutzt wird, sondern eine davon abgeleitete Zahl, aber die Erklärung würde den Rahmen dieses Artikels sprengen.)

Wenn du eine neue Sitzung öffnest, solltest du, bevor du mit dem Austausch empfindlicher Nachrichten beginnst, den Schlüssel deines Kommunikationspartners anzeigen lassen. Sobald du diesen hast, benutzt du eine unabhängige Kommunikationsmethode (eine andere Anwendung, einen Telefonanruf, Hauptsache irgendwas, das mit der Chat-Anwendung möglichst wenig zu tun hat), um sicherzustellen, dass dies in der Tat der Schlüssel deines Kommunikationspartners ist. Danach macht ihr das Ganze nochmal andersrum.

Dieses Spiel muss jedes Mal wiederholt werden, wenn der Schlüssel sich ändert. Zusätzlicher Hinweis: In manchen Anwendungen kann es möglich sein, einen Schlüssel für eine Man-In-The-Middle-Attacke einzuspeisen und danach den ursprünglichen Schlüssel zurückzuspielen. Durch die Funktionsweise der Algorithmen (schlag „Double Ratchet“ nach, wenn du mehr wissen willst) kann der eingespielte Schlüssel ältere Nachrichten nicht öffnen, aber er kann alle zukünftigen Nachrichten entschlüsseln, auch, nachdem der ursprüngliche Schlüssel wiederhergestellt wurde. In diesem Falle ist der einzige Hinweis, dass etwas Zwielichtiges geschieht, eine ungleiche Anzahl von Schlüssel-Änderungen, d.h. Person A sieht eine Schlüssel-Änderung und Person B sieht 3, oder Person A sieht 0 und Person B sieht 2.

Das bedeutet, dass nicht nur die Schlüssel selbst auf beiden Seiten identisch sein müssen, sondern auch die Anzahl der Schlüssel-Änderungen.

Wenn du den Schlüssel deines Kommunikationspartners nicht über einen unabhängigen Weg verifizierst, kannst du der Kommunikation niemals vollständig vertrauen. Interessanterweise ist dieser Punkt genau das, was PGP so mächtig macht: Da die Schlüssel nicht automatisch ausgetauscht, sondern manuell kommuniziert werden, kann man dir nur sehr schwerlich einen falschen Schlüssel unterjubeln.

4.7. Begrenzender Faktor 7: Sonstige Daten

Der größte Packen zusätzlicher Daten ist derjenige, den wir als Metadaten bezeichnen. Diese Metadaten sind üblicherweise nicht verschlüsselt und können sehr einfach mitgeschnitten werden, auch dann, wenn der eigentliche Kommunikationsinhalt sicher ist. Zu den Metadaten gehören alle Informationen, die nicht Teil der Nachricht selbst sind: IP-Adressen, Kommunikationsteilnehmer*innen, Sendezeiten, Gerätemerkmale etc. Selbst dann, wenn der Nachrichteninhalt nicht bekannt ist, können Metadaten von interessierten Parteien dazu genutzt werden, um etwa herauszufinden, wer mit wem kommuniziert, wann und wie oft Nachrichten ausgetauscht werden, an welchem Ort die Gesprächsteilnehmer*innen sich befinden, welche Geräte und Software sie benutzen usw. Bei PGP-verschlüsselter E-Mail verbleiben Betreffzeilen und Anhänge ebenfalls im unverschlüsselten Klartext.

Metadaten können ausreichend sein, um die Vernetzungen zwischen Personen zu modellieren.

Server speichern gerne Metadaten wie IP-Adressen, Verbindungszeiten und Geräteinformationen als Teil ihrer Logs. Wenn du deine Server-Admins nicht kennst und keine Möglichkeit hast, herauszufinden, welche Daten gespeichert werden und wer dazu Zugang hat, musst du davon ausgehen, dass alles gespeichert und weitergegeben wird. Wenn nötig, musst du zusätzliche Maßnahmen einsetzen, um deine Daten zu anonymisieren, z.B. durch die Verwendung von VPN, Tor, oder eines Browsers mit guten Privatsphäre-Einstellungen.

Metadaten sind jedoch nicht die einzige potenziell gefährliche Datenspeicherung: Lokale Caches, Backups, System-Logdateien, Screenshots und andere zusätzliche Datenspeicherung kann dazu führen, dass empfindliche Daten unbeabsichtigt zugänglich gemacht werden.

5. Also was muss ich jetzt tun?

5.1. Kurz und knapp als Liste

  • Benutze Ende-zu-Ende-Verschlüsselung.
  • Verifiziere Schlüssel über einen unabhängigen Kommunikationsweg und pass auf, wenn der Schlüssel sich ändert.
  • Benutze starke Passwörter und verlasse dich nicht auf Face ID oder Fingerabdrucksensoren. Ein Passwortmanager kann hilfreich sein.
  • Verwende Multi-Faktor-Authentisierung wo möglich.
  • Halte dein Betriebssystem und deine installierten Anwendungen auf dem aktuellen Stand, da Updates Sicherherheitslücken schließen.
  • Tu dasselbe für sämtliche Geräte in deinem Heimnetz, aber ganz besonders für deinen Router.
  • Mach regelmäßige Backups deiner wertvollen Daten, da du im Falle einer Attacke wahrscheinlich dein System plattmachen musst.
  • Deaktiviere alle unnötigen Dienste und Zugangsmodi.
  • Verschlüssele deine Platte und jegliche Datenträger.
  • Speichere niemals empfindliche Daten unverschlüsselt in „der Cloud“ oder auf nicht vertrauenswürdigen Geräten.
  • Pass auf, mit wem du ein Gerät teilst. Verwende Gastzugänge.
  • Installiere keine fragwürdigen Anwendungen und nimm keine Änderungen an deinem System vor, die du nicht vollständig verstehst.
  • Wenn ein Arbeitgeber dich zwingt, Überwachungssoftware zu installieren oder Änderungen der Systemeinstellungen vorzunehmen, oder wenn eine nicht vertrauenswürdige Person Zugang zu deinem Gerät hatte, ist dieses Gerät nicht mehr für sichere Kommunikation geeignet.
  • Benutze VPN oder Tor, wenn du deine IP-Adresse verschleiern möchtest.
  • Kombiniere das mit einem Browser, der Fingerprinting reduziert, wenn du nicht identifiziert werden willst.
  • Die sichersten Daten sind die, die es nicht gibt. Löschen ist gute Sicherheitspraxis.

Wenn diese Liste dich ein bisschen überfordert, halte dir vor Augen, dass jede einzelne dieser Maßnahmen zu deiner Sicherheit beiträgt. Es ist besser, dich nur teilweise zu schützen, als dich überhaupt nicht zu schützen. Ich hoffe, dass dieser Artikel dir geholfen hat, zu verstehen, wogegen jede dieser Maßnahmen dich schützt, damit du selbständig entscheiden kannst, welche davon du unter welchen Bedingungen einsetzen möchtest.

5.2. PGP ja oder nein?

PGP ist ein mächtiges Werkzeug, um die Sicherheit von verschlüsselten Inhalten zu gewährleisten. Durch seinen Aufbau macht es es nicht nur nahezu unmöglich, falsche Schlüssel einzuspeisen, sondern bringt auch Funktionalität mit, um Schlüssel zu signieren und ein Netz des Vertrauens aufzubauen. Wenn du einen ausreichend vertrauenswürdigen PGP-Schlüssel für deine Kommunikation benutzt und beide Teilnehmer*innen gute Sicherheitspraxis befolgen (also so was wie starke Passwörter, keine Verwendung Malware-verseuchter Geräte usw.), kannst du dir sehr sicher sein, dass deine Nachrichten nur von der Person gelesen werden können, der du sie geschickt hast.

Da ein PGP-Schlüssel jedoch schon vom Prinzip her an eine Identität gekoppelt ist, ist er zwangsweise ungeeignet für anonyme Kommunikation. Ohne beträchtlichen Aufwand und ungewöhnliche Anwendungsmethoden ist unmöglich, Autor*innenschaft von PGP-verschlüsselter Kommunikation abzustreiten (technisch gesehen eigentlich die Empfänger*innenschaft, aber bei einem zweiseitigen Gespräch kommt das auf dasselbe raus). Die größte Stärke von PGP ist gleichzeitig seine größte Schwäche.

5.3. Verschlüsselung ist nicht gleich Anonymität

Dieser Artikel hat beschrieben, wie du den Inhalt deiner Kommunikation absicherst. Dies ist nicht ausreichend, um deine Identität vor den Empfänger*innen zu verstecken, und noch weniger, um sie vor dem Server geheimzuhalten, der deine Kommunikation verarbeitet. Eine Anleitung für anonyme Kommunikation würde ihren eigenen Artikel brauchen, aber für den Moment will ich dir zumindest eine kurze und potentiell unvollständige Liste mitgeben von Faktoren, die dich identifizierbar machen, und wie du sie verschleierst.

  • Browser Fingerprint: Macht dich identifizierbar gegenüber jedem Webserver, mit dem du über deinen Browser Kontakt aufnimmst. Diesen Fingerprint zu anonymisieren, ist sehr anspruchsvoll. Er kann in Server-Logs vorgehalten werden und auch dazu genutzt werden, deine Aktivitäten quer durch das Internet zu verfolgen.
  • IP-Adresse: Identifiziert dich gegenüber jedem Server, mit dem du kommunizierst, aber in der Regel nicht gegenüber den Empfänger*innen deiner Nachrichten, die deine IP üblicherweise nicht einsehen können. VPN und Tor maskieren deine IP. IP-Adressen werden sehr oft in Server-Logs gespeichert. Wenn du die Server-Log-Regeln nicht kennst, musst du davon ausgehen, dass jede einzelne IP, mit der du jemals mit dem Server kommuniziert hast, für immer und ewig gespeichert wird.
  • Geräteinformationen und andere Metadaten: Werden möglicherweise von einer Anwendung ohne dein Wissen an den Server gesendet. Werden möglicherweise den Empfänger*innen zugänglich gemacht. Ein anschauliches Beispiel wären E-Mail-Header. Viele Apps erlauben keine anonyme Kommunikation und machen nicht transparent, welche Daten gesendet und gespeichert werden.
  • Kontaktdaten: Wenn du einen Account mit deiner E-Mail-Adresse oder deiner Handynummer registrierst, ist deine Identität dem Betreiber des Dienstes automatisch bekannt. Manchmal is es möglich, diese Informationen vor den Empfänger*innen zu verstecken, aber darauf sollte man sich nicht verlassen.
  • Soziales Netz: Wenn du dich bei einem Dienst anmeldest und mit denselben Personen verbindest, mit denen du auch auf anderen Diensten und/oder im echten Leben vernetzt bist, können diese Verbindungen herangezogen werden, um dich zu identifizieren, und zwar auch dann, wenn es keinerlei andere identifizierende Faktoren gibt.
  • Bilder, Selbstbeschreibungen, alles, was du postest, ist ja klar: Was du löschst, wird oft nicht wirklich gelöscht und kann später immer noch benutzt werden, um dich zu identifizieren. Auch Daten, die vom Server tatsächlich gelöscht werden (große kommerzielle Dienste löschen NICHTS), können sie in Backups überleben.
  • Der zur Verschlüsselung benutzte Schlüssel: Dies ist besonders leicht ersichtlich im Falle von PGP, wie zuvor erklärt. Wenn der Schlüssel in irgendeiner Form mit deiner Identität verknüpft ist, hebelt er jegliche Anonymität automatisch aus.

Themen: deutsch, computer, security

How to guarantee the security of encrypted communication

05. December. 2023

My messages are encrypted. Is that enough?

Short answer: Somewhere between “no” and “it depends”. For the long answer and explanation what it depends on, read on.

Click here for PDF version

Hier klicken für deutsche Version

What this article is: An overview of factors that affect the security of message exchange over the web. It is directed at people who would like to learn how to better protect themselves. It aims to provide a general understanding of the topic and empower readers to evaluate their threat models and choose the right tool for the job. Towards the end, you will be given a list of best practices that you need to follow in order to have secure communication. The purpose of this article is to give you enough knowledge to understand what problems each of the points on that list solves.

What this article is not: An in-depth explanation of current technology, a list of recommended services, or in any way interesting for people who deal with this stuff on a daily basis.

Structure:

  1. Why do we need encrypted messaging?
  2. Threat models: What are we defending against?
  3. Basic knowledge
    1. Encryption keys
    2. Message transmission over the internet
    3. Types of attacks
  4. Which factors limit the security of encrypted message exchange?
    1. Limiting factor 1: The user
    2. Limiting factor 2: The device, its OS, its configuration
    3. Limiting factor 3: The app
    4. Limiting factor 4: The server(s)
    5. Limiting factor 5: The connection
    6. Limiting factor 6: The key verification (or lack thereof)
    7. Limiting factor 7: The rest of the data
  5. So what do I actually need to do?
    1. The quick and dirty list
    2. To PGP or not to PGP?
    3. Encryption is not anonymity

1. Why do we need encrypted messaging?

Or: I don’t need this because I do not commit crimes!

In an ideal world, someone who does not act immorally would have nothing to fear by communicating without complex safety layers. Sadly, we do not live in an ideal world.

In reality, we have much to defend against: We have to defend ourselves against adversaries from our personal lives (ex-boyfriends, abusive parents and the likes) or from our business lives (your own employer, as well as any interested parties that would like to get their hands on your business partners’ or your employer’s internals and/or their money), as well as, yes, against governments.

This does not mean that this information is intended to serve people who wish to commit evil acts. On the contrary: It is without question that governments often act in evil ways. Not only do they frequently break their own laws, but laws themselves are often morally wrong. Across the globe, authoritarian governments can be found just as often as those which apparently strive to get there. Peaceful protesters, journalists, pregnant people, queer and trans people, women, racial, cultural and religious minorities and many other groups regularly suffer injust and immoral, albeit often legal, repression. Protecting one’s communication data can help reduce the impact of repressive acts. It is, I hope, an obvious truth that breaking unjust laws is an ethical imperative.

2. Threat models: What are we defending against?

The concept of threat models in IT is usually intimidating to people not immersed in the topic. This is not because they are hard to understand, but because they are usually presented by listing the names of tools, protocols and software that most people have never heard of.

In human-understandable terms, a threat model is simply a concept of what (or who) you are defending yourself against. You are already aware of most of them.

You have a need to protect yourself against:

  1. Automated attacks, aimless scam / spam / phishing attempts: These are often high-volume, low-cost. If one mark among thousands pays out, it is already a profit.
  2. Automated analysis of your data for the purpose of advertisement and influencing your behaviour: While this is often seen as a nuisance rather than a security risk, it is also that. Your data can be used to inform an interested party of your political leanings, your medical condition including pregnancy and abortion, your whereabouts, your media preferences, and much more.
  3. Automated analysis of your data for the purpose of detecting real or presumed violations of laws and term of services (TOS), such as copyright violations, CSAM, terrorism, sex work, etc.: Some of these TOS and laws are morally wrong and deserve to be broken. Some of them simply do not justify the immense violation of privacy that comes with scanning and evaluating private message exchange. And in many cases, automatic detection of a presumed violation of laws or TOS has already ruined a person’s life without them ever doing what they were accused of. Corporations are not required to justify their punitive actions to anyone.
  4. Analysis of connections between people in order to model the social structures of movements and organisations (social network analysis): This method is often used to identify leaders of movements or informal organisations so they can be singled out and targeted. This is used for example for union busting or for destroying human rights movements and any organisations a government may deem a threat, irregardless of its legality or morality.
  5. Physical or remote access to your devices: People with access to a device may intentionally or accidentally install spyware / malware or perform changes to the system. Uninvited interested parties can gain physical access to devices by infiltrating home or work spaces, or in the case of authorities, by simply confiscating them, for example during a search of your person or your home.
  6. Sniffing and/or manipulation of private communication by third parties: The third party here can be your local stalker, or it can be someone who wants to make your business partner send the large sum of money to the interested party’s bank account in one way or another. It is generally someone who in interested in their target personally and the attacks are carried out manually. The interested party may install trojans, use exploits, utilise social engineering) techniques, or depending on their resources go so far as to install hardware surveillance technology (let’s be real, if it gets that far, most of us have already lost).

3. Basic knowledge

3.1. Encryption keys

When we are talking about modern encryption methods and end-to-end encryption in messaging, we are virtually always talking about asymmetric encryption. This means that every key comes as a pair of a public and a private key.

If person A and person B would like to communicate, at the start of the exchange both A and B have only their own set of public and private keys.

A has these keys:

  • A-public
  • A-private

B has these keys:

  • B-public
  • B-private

A public key is used to encrypt a message, and a private key is used to decrypt it. There is no other way to decrypt a public-key encrypted message than with the matching private key. (There are some additional interesting quirks, but knowing them is not necessary for our purposes. Look up how cryptographic signatures work if you would like to learn more.)

In order to encrypt the message that A wants to send to B, A needs to receive B’s public key in some way or other, and in order to reply, B needs A’s public key. So, after the initial exchange of keys,

A has these keys:

  • A-public
  • A-private
  • B-public

B has these keys:

  • B-public
  • B-private
  • A-public

The advantage of asymmetric encryption over symmetric encyrption, in which the same key is used for encryption and decryption, is the fact that a third party that intercepts the initial key exchange cannot decrypt the messages. A public key is called that because it is truly public: Even when it is known to uninvited third parties, the communication remains secure.

Modern algorithms with multiple valid keys (see: double ratchet) add much complexity, but knowing how this principle works helps us understand two very important basic facts:

  1. Before end-to-end encrypted communication begins, keys are exchanged. This is always true, even when it happens invisibly, and the fact that it often happens invisibly is a problem we will talk about later in the section on key verification.
  2. If the key is the only layer of security (as in: you do not need to enter a password every single time you receive a message in order to read it), then whoever has your private key can read all your messages.

3.2. Message transmission over the internet

This section serves to explain the basic elements of message exchange over the web, and the potential points of attack.

Let us consider the simple scenario: Person A uses Device 1 to send a Message that is received by Device 2 and read by Person B.

Person A ⇒ Device 1 ⇒ transmission ⇒ Device 2 ⇒ Person B

How many potential points of attack can you identify? I will give you a minute to think about it. No, really do. How many points of attack are in this image?

Have you thought about it? Do you have an answer? The answer is seven.

  • The message can be intercepted on its way.
  • Device 1 and Device 2 can be compromised.
  • So can Person A and Person B.
  • An often ignored risk factor is the environment that person A and B are in, where intentional or accidental observation by third parties can take place.

If this simple layout seems manageable, I’m sorry to tell you that it’s about to get much worse, because this would only be true if A and B communicated directly, for example by sending the message via Bluetooth. The internet, however, is anything but direct.

The first additional node we need to add in the middle is the server. Virtually every service we use online runs through a server that receives the message and delivers it to its recipient. This is the case for a centralised service, such as Telegram or Signal.

Now our little diagram looks like this:

Person A ⇒ Device 1 ⇒ transmission ⇒ Server ⇒ transmission ⇒ Device 2 ⇒ Person B

In case of a decentralised service such as e-mail or Matrix, where multiple servers communicate and A and B have their accounts in different places, it looks a little bit worse:

Person A ⇒ Device 1 ⇒ transmission ⇒ Server 1 ⇒ transmission ⇒ Server 2 ⇒ Device 2 ⇒ Person B

But, I did warn you, it gets even worse. Let’s look at the “transmission” part. It seems straightforward, doesn’t it? Your bits travel through the air or through wires and arrive at their destination… Only they don’t, at least not directly. “Transmission” is a shorthand for everything that happens in between, so let’s remove the shorthand and look at the reality.

Consider your home network: There’s a router in between you and the internet, and it receives and reroutes every single bit of data you send and receive. And between you and your server, there are a dozen routers whose only purpose is pushing those bits into the right cable… Or, in some cases, to store those bits and analyse them and surveil their senders.

Now our neat little scenario of sending one message looks kind of like this:

Person A ⇒ Device 1 ⇒ Router ⇒ Router ⇒ Router ⇒ Server 1 ⇒ Router ⇒ Router ⇒ Router ⇒ Server 2 ⇒ Router ⇒ Router ⇒ Router ⇒ Device 2 ⇒ Person B

Thanks, I hate it. And this is a gross oversimplification — in reality there’s way more steps in between. You can try this at home if you install a traceroute program and simply run it on random domains you like to visit. You will usually see dozens of hops, and each of them is basically a computer that can run its own code and do with the data you sent what it pleases. If your data is not encrypted, that also means each of these nodes knows the contents. So if you, for example, send an unencrypted e-mail over an unsecured connection, then every single of the machines it passes through now potentially knows the content of your e-mail. If you send a password over plain HTTP, then every one of them knows your password. If you visit a plain HTTP website, every one of these nodes can serve you a false website. Before the widespread adoption of SSL/TLS, this is what we used to do. It is unclear how we managed to survive that phase of the internet. We will talk more about TLS and certificates when we talk about the connection as a security-limiting factor. For now, let’s just say this: Encryption is the only thing that prevents all of your online communication from being read by a dozen little spies 100% of the time.

Having a basic idea of how messages travel over the internet teaches one crucial lesson: There are dozens of potential risk factors between the sender and the recipient, and some of them are social.

3.3. Types of attacks

In order to understand what we are defending ourselves against, we must have a basic idea of the ways in which our data can be compromised. The description of these methods could fill an entire book, therefore this section describes only a few select techniques very broadly.

  • Spyware: Spyware is a type of malware that is installed on a system. Many spyware applications are sold the same as regular software and can even be installed through app stores. Spyware is often advertised for the purpose of surveilling the activity of children or employees of an enterprise. Many of the applications that are installed on work devices contain spyware. Spyware may for example include a keylogger, it can track online activity, take screen captures, log location data, utilise cameras and microphones and send all this to a configurable recipient, without the surveilled person ever noticing. In many cases, the installed spyware application is either hidden or disguised as benign software, for example a calculator app.
  • Man In The Middle: This is a type of attack that does not take place on your own device, but somewhere between the sender and the recipient. An interested party intercepts the communication between A and B and either passes it on unchanged or applies certain changes. A and B are under the impression that they are talking directly to each other. If the messages are not altered, it is possible that A and B never realise that they are being surveilled. An example for the manipulation of messages would be the Man In The Middle intercepting an e-mail that contains bank account data and changing it to point to their own bank account before passing the e-mail on to the recipient.
  • Alteration of browser, app or system settings: This can be done either manually or for example by running a script or application that needs to be executed only a single time in order to make permanent changes. These changes could for example be additional user accounts, the installation of TLS root certificates (we will talk about this later) or the activation of certain services. These things can allow an interested party to access private data.
  • Acquisition of login data: If the interested party knows a password, it can use this password to log in and copy data. Especially system accounts or for example a user’s Apple, Microsoft or Google accounts often contain large amounts of very sensitive data which is accessible to everyone who has the password. Acquisition of login data is especially easy if insecure passwords are used, if passwords are reused, if a user is observed while entering a password, or if the data is entered on an unsafe system that contains spyware. Multi factor authentication can minimise this risk.
  • Social engineering and phishing: There are many methods to get a target to install spyware, change settings or enter login data on fake websites. Some of them are so sophisticated that even professionals struggle to identify them.

4. Which factors limit the security of encrypted message exchange?

We can apply the information from the basic knowledge we just talked about to identify the factors that limit protection against the threats from our threat model. This helps us understand which protections we need and why we need them.

4.1. Limiting factor 1: The user

Your own behavior limits your security.

How secure are your passwords? Do you reuse passwords? Do you write them down in a notebook? Who has access to the notebook? Do you store them in a password manager? How secure is your password manager?

What networks do you trust? Do you use unsecured connections?

Do you keep your system up to date? Do you install random software and hope for the best?

What devices do you trust? Do you use a computer that other people have access to? Who are they?

Do you hand over your data to other people? Do you store some of your data in insecure places? Do you upload backups to unencrypted cloud services?

Can you identify phishing attacks? Do you use multiple factor authentication? Do you plug in any USB stick that a stranger gives you? Do you let random people use your device?

Do you verify encryption keys?

We will talk about most of these questions in more detail. The important takeaway from this section is that your digital safety is controlled mainly by yourself. Nobody else will do it for you, and even a reasonably secure system will not provide security if it is not used in the right way.

4.2. Limiting factor 2: The device, its operating system, its configuration

All data that you can access without entering a password can be copied and altered by everyone with physical access to your device. Face ID and fingerprint authentication are child-proofing and do not provide security. A photo of your face can be enough to open a Face ID lock, and your fingerprints can be lifted directly from the device they unlock. There is no secure alternative to good passwords. Patterns and PINs count as passwords, but must be very long and random to provide the same level of security as a password.

However, a secure login password will not save you if your data is not encrypted on the drive itself. Why not?

Imagine you have a USB drive connected to your laptop. If your screen is locked, only someone who knows your password can log in to access the data on the stick. Except, if the stick is not encrypted, they can just pull it out, stick it in their own laptop, and copy or change all your data. Now, understand that the hard drive in your laptop (or the one in your computer, or the storage in your phone) is only a slightly less convenient USB stick.

Therefore, we need disk encryption in order to have data that is what we call “secure at rest”: When the device is switched off or disconnected, there is no way to retrieve the data on the drive without also having the password and/or the key file (which of these to use depends on whether or not you expect an attacker to be able to find and use a key file that you keep on a separate device, or to obtain your password in some way).

Why do we call it “secure at rest”? Because it is not secure in operation. While the drive is in use, the encryption key is in your device’s RAM. Someone who has access to the device can dump the RAM contents (for example by cold boot attack) and obtain the key. Disk encryption without login protection is as useless as login protection without disk encryption. So yes, you do need both: One secure password that you enter every time you access the device (yes, even your phone) and one secure password for encrypting the actual data on your drive.

Having these two things does not mean your device is automatically safe: Any malware that runs on the system can access your data; so can any malicious hardware like for example hardware keyloggers that simply detect and store every single thing you type.

This leads us to another conclusion: As soon as an untrustworthy party has had physical access to your device, you need to consider both its hardware and its software as burned. You may be able to retrieve your precious data from its drive, but under no circumstances should you turn the device on and enter your passwords in order to do so. Any executable on the machine, including its UEFI or its bootloader, is as dangerous as its potentially modified hardware.

During normal usage, there are best practices that should be followed to ensure a safe environment on your operating system:

  • Do not install or execute software that you do not trust, as it could be malware/spyware and it could make changes that remain even after uninstalling the software.
  • Do not make changes to your system or your browser that you do not understand, as you could be changing settings that affect your security.
  • Keep your system and all software up to date, as updates usually contain security fixes. (As a side note: It is possible for malicious software to be included in updates, which is why environments with extremely high risks sometimes disable automatic updates and only apply them after checking. For everyday applications, automatic updates are a good solution.)
  • Do not run unnecessary services. Everything that communicates to the outside is a potential source of problems.
  • Uninstall unused software. Things that aren’t there cannot cause problems.
  • If anything seems wrong or you have reason to believe that your system is compromised, you need to do a full reinstallation / factory reset. You can backup files (pictures, documents, browser bookmarks etc.) but you should not backup any settings or configuration files that you cannot (or do not know how to) manually check for correctness, because they could contain customisations that open backdoors.
  • Once your system is compromised, you must work under the assumption that everything that was on your screen has been seen, every one of your files has been opened, and every keystroke you have made has been logged. This also means that you must change all of your passwords (and that doing this while using the compromised system is pointless).
  • If your employer expects you to install specific software or make changes to your system, avoid using your work system privately, as these applications often include spyware and the changes may make it possible to intercept your communications.

4.3. Limiting factor 3: The app

If you are sending encrypted messages, you are almost certainly using an application to do so. This app may run in a browser or on your device directly. In both cases, you need to be able to trust the app:

  • You need to trust that the app you downloaded has not been manipulated on its way and is really the correct app and not an impostor. App Store and Google Play are very good at ensuring the further and atrocious at the latter. If you use a Linux/BSD package manager, you can only be sure about the veracity of the software if packages have signatures and if these signatures are checked. Not every package management system supports signing. If you download the software directly from a website, you need to be sure that the website is the correct one.
  • Even if you have the correct app, that does not necessarily mean you are safe. The app may have exploitable security issues, or the distributor may intentionally have inserted backdoors to be able to spy on its users. Governments may have requested or mandated those backdoors. The app may even go so far as to scan your messages proactively for the purpose of targeted advertising or to comply with government requirements (chat control). These points are where open source software shines: People who care about security will read the code and ring the alarm bells if they discover backdoors or surveillance code.
  • Is the encryption true end-to-end encryption? Does the data get decrypted on your device and your device only? If you lose your device and your password at the same time, is there any way at all to recover your data? If the answer is yes, this point is to be considered a fail and the encryption is not secure.

4.4. Limiting factor 4: The server(s)

Server configuration is usually intransparent to the user. This is a problem because servers have access to an immense amount of data, even in the case of true end-to-end encryption. It is also a point in favour of utilising decentralised services and choosing a server whose operator you can trust to both care about your privacy and be competent enough to ensure it through the server’s configuration.

If you are using a closed-source service, it is hard to know whether or not the server receives your key at any point, or if it possesses the ability to decrypt and analyse your data, effectively compromising the concept of end-to-end encryption.

Web apps (those are applications you access through your browser, for example Telegram or Whatsapp on your computer, or the Element web interface): As the application is not installed locally, every visit of the website equals downloading a new version of the app. If the server is compromised, it may send you a false website and steal all of your data.

Even if your messages are fully encrypted, cannot be read by the server, and the server has not been compromised, storing unnecessary additional data can get you into deep trouble (see the section on “the rest of the data”).

4.5. Limiting factor 5: The connection

As mentioned before, messages on the internet are passed on across many different routing points. One of them is generally under your control, and that is your router. If your router is running malware, you are in for a bad time. Routers need to be thoughtfully maintained like any other device: Secure passwords, regular updates, factory resets of second-hand devices.

These days, the vast majority of data sent over the internet is encrypted with TLS. This means that even data that does not have its own encryption layer cannot easily be sniffed or manipulated by third parties, including any of the routers passing it on. TLS is fairly secure in that it cannot just be broken from outside, and you need to have access to either the server or the client in order to access or manipulate the data being transmitted.

In order to understand in which cases we can or cannot trust TLS, we need to understand a little bit about how TLS works.

A secure connection via TLS is established by something called the TLS handshake. This handshake serves to establish session keys that use symmetric encryption, which requires less computing power and is therefore better suited for bulk data transfers. In order to prevent third parties that surveil the connection from being able to obtain the session keys, the messages they are sent in are encrypted with a different algorithm.

Each TLS server has a public/private key pair. The handshake message sent by the client is encrypted with the server’s public key, and only the server can decrypt this message, because (hopefully) nobody else has the server’s private key.

The challenge with asymmetric encryption is identity verification: You need to be able to ensure that the key you have received really does belong to the person that you think has sent it. In TLS, identity verification is solved by way of certificates. There are a number of Certificate Authorities (CAs) which own so-called root certificates. Through a “chain of trust”, these root certificates are used to sign intermediate certificates that are then in turn used to sign the server certificate, which contains, among other things, the server’s public key. If the server has a certificate that your operating system and your browser accept as valid, this means that ultimately, one of the CAs whose root certificates you have saved on your computer (they are shipped and updated with your operating system or your browser) has verified that the public key you are using belongs to the server you are talking to.

This makes root certificates the point at which TLS can be broken. If a malicious root certificate is marked as trusted on your system, this malicious root certificate can be used to sign malicious server certificates, which are then automatically trusted by your device, making it possible for the malicious actor to carry out Man-In-The-Middle attacks.

It is possible to manually install additional root certificates. You could create your very own root certificate, and anyone that saves it on their system among the trusted certificates would automatically trust any certificate signed by you. In fact, many employers do exactly this.

These facts add up to the following limitation:

TLS is only secure if 1. no malicious certificates have been installed for example through user error, employer demand, malware activity, or unauthorised device access and 2. the CAs are themselves trustworthy.

As the large CAs are under control of large corporations, most of which are located in the USA, in order to fully trust TLS, you need to not only trust your device and the software you are using, but also the corporations controlling TLS root certificates es well as the governments of the countries they are in. This is why an additional cryptographic layer of end-to-end encryption is necessary to protect sensitive information.

If your personal threat model means that TLS is not trustworthy, or if governments succeed in forcing their own root certificates to be automatically trusted, web apps are no longer a secure choice for communication, even if they possess their own encryption (Matrix, Telegram, …), as a Man In The Middle could simply serve a false website that extracts or manipulates your data. This is less easy with standalone applications; however, many mobile apps are at their core simply a browser, so the problem may remain.

Using VPN or tor-browser does not make your connection more secure. They only hide your physical location by masking your IP address. You may still be identified through browser fingerprinting and there is no additional encryption to protect the content of your messages. Only Tor onion services use their own cryptographic layer and do not rely solely on TLS for security.

4.6. Limiting factor 6: The key verification (or lack thereof)

Most messenger apps these days utilise end-to-end encryption through asymmetric algorithms. When you open a new chat, public keys are exchanged automatically. You begin communicating and you simply trust that the keys were exchanged correctly, that no Man In The Middle served both of you their own key with the intention of intercepting or manipulating your communication.

If your communication is sensitive or you have reason to believe that you are being targeted, you should not simply trust.

Security-focused applications always offer a way to show the keys used in a chat session. They are not always called keys; they may be called safety numbers or may be presented through emoji, which does not make it easy to give a universal description. If in doubt, ask a search engine how to verify keys in your specific app. (Technically, what you will be comparing here is not the actual key that’s used to encrypt the messages, but a number derived from it, but this explanation is a bit more involved than this article allows for.)

When you open a new session, before you begin with any sensitive communication, you should tell the application to display your communication partner’s key. Then you use an independent mode of communication (a different application, a phone call, literally anything outside the application itself) to verify that this is, in fact, their key, and do the same the other way round.

This needs to be repeated every time a key change occurs. As a side note, in some applications it may be possible to insert a key for a man-in-the-middle attack and then change it back to the original key. Because of the way that the algorithms work (look up “double ratchet” to learn more), the inserted key cannot decrypt older messages, but can be used to decrypt all future messages even after the original key has been reestablished. If this happens, the only hint that something is wrong may be an unequal number of key changes on both ends, e.g. person A sees one key change and person B sees 3, or person A sees 0 changes and person B sees 2.

Therefore, not only do the keys need to be identical, but the number of key changes needs to match up as well.

If you do not manually verify your communication partner’s key through an independent communication pathway, you can never fully trust the communication. Incidentally, this is what makes PGP so powerful: Because the keys are not exchanged automatically but communicated manually, you cannot easily be served a false key.

4.7. Limiting factor 7: The rest of the data

The biggest chunk of extra data is what we call metadata. This metadata is usually not encrypted and can very easily be sniffed, even if the actual content of the communication remains secure. Metadata includes all information that is not contained in the message itself: IP addresses, communication partners, send time, device identifications, etc. This means that even without knowing the content of the communication, interested parties are often able to find out who is talking to who, when and how often messages are exchanged, the location of the participants, what devices and software they use, and similar information. In the case of PGP encrypted e-mail, subject lines and attachments remain unencrypted.

Metadata can be sufficient to model connections between people.

Servers may store metadata such as IP addresses, connection times and device information as part of their server logs. If you do not know your server admin and have no way to find out which data is or is not stored and who has access to it, you must assume that it is stored and passed on. If necessary, you must take additional steps to anonymise your data for example by using a VPN, Tor, or a privacy focused browser.

But metadata is not the only potentially dangerous data storage: Local caches, backups, system log files, screenshots, and other additional data storage may accidentally make sensitive data accessible to unauthorised parties.

5. So what do I actually need to do?

5.1. The quick and dirty list

  • Use end-to-end encryption.
  • Verify keys through an independent mode of communication and pay attention to key changes.
  • Use strong passwords, do not rely on Face ID or fingerprints. A password manager can help.
  • Use multi-factor authentication where possible.
  • Keep your operating system and your applications up to date, as updates usually include security patches.
  • Do the same for all devices in your home network, but especially for your router.
  • Keep good backups of your valuable data, because in case of an attack, you may need to wipe your system.
  • Disable all unnecessary services and access modes.
  • Encrypt your disk and any storage devices.
  • Never store sensitive data unencrypted in “the cloud” or on untrusted devices.
  • Be careful who you share a device with. Utilise guest accounts.
  • Do not install sketchy applications or make changes to your system that you do not fully understand.
  • If an employer forces you to install surveillance software or make changes to your system, or if an untrusted person has had access to your device, these devices are no longer suitable for secure communication.
  • Use VPN or Tor if you wish to mask your IP address.
  • Combine these with a browser that reduces fingerprinting if you do not wish to be identified.
  • The most secure data is data that does not exist. Delete what you can.

If this list seems overwhelming, keep in mind that every single of these measures improves your security. Protecting yourself imperfectly is better than not protecting yourself at all. I hope that this article has helped you understand what exactly each of these best practices protects you against, so that you can more competently choose which of them to utilise under which circumstances.

5.2. To PGP or not to PGP?

PGP is a powerful tool for guaranteeing the security of encrypted content. Because of the way it is designed, not only does it make the serving of false keys all but impossible, but it also comes with functionality for signing keys and establishing a web of trust. If you are using a sufficiently trusted PGP key to communicate, and both participants are following good security practices (including but not limited to strong passwords, not using malware-infested devices, etc.), you can be very certain that your messages can only be read by the person you sent them to.

But because PGP keys are inherently tied to an identity, they are by design unsuitable for anonymous communication. Without significant efforts and nonstandard ways of usage it is impossible to deny authorship of PGP encrypted communication (technically it’s recipientship, but in case of a two-sided conversation, there’s no difference). The greatest strength of PGP is also its greatest weakness.

5.3. Encryption is not anonymity

This article explained how to protect the content of your communication. This is not sufficient to hide your identity from the people you are speaking to, and even less to hide it from the server that processes your communication. Explaining how to communicate anonymously would require its own article, but for now I will simply give you a short and potentially incomplete list of things that identify you, and how to obfuscate them.

  • Browser fingerprint: Identifies you to every web server you access with your browser. Anonymising it is very difficult. It can be kept in server logs and be used to track you across the web.
  • IP address: Identifies you to every server you communicate with, but not to the recipient of your messages, who usually cannot see your IP. VPN and Tor hide your IP. IP addresses are often kept in server logs. If you do not know the server log policy, you must assume that every single IP address you ever accessed it with is stored forever.
  • Device information and other metadata: May be sent to the server by an application without your knowledge. May be accessible to the recipient. An easily visible example would be e-mail headers. Many apps do not allow anonymous communication and are not transparent about which data is sent and stored.
  • Contact data: If you have registered an account with your e-mail address or your phone number, then your identity is known to the service operator. It is sometimes possible to hide it from a recipient, but this is not very reliable.
  • Social net: If you register with a service and connect with the same people as on other services and/or in real life, these connections can be used to identify you even in the abscence of any other identifying data.
  • Pictures, self-descriptions, anything you post, obviously: Things that you delete are often not actually deleted and can be used to identify you later. Even when they are really deleted from the server (large commercial services do NOT delete stuff!), they may still live on in backups.
  • The encryption key: This is especially apparent in the case of PGP, as explained before. If the key is tied to your identity in any way, then it automatically negates all anonymity.

Themen: english, computer, security