- Twitters (X) neue verschlüsselte DM-Funktion (XChat) wirbt technisch mit End-to-End-Verschlüsselung, weist aber weiterhin schwerwiegende Sicherheitsmängel wie Diebstahl privater Schlüssel, MITM und die Offenlegung von Metadaten auf
- Zwar wurde Libsodium Box (schlüsselbasierte Verschlüsselung) eingeführt, doch wegen fehlender Forward Secrecy und eines schwachen, auf einer 4-stelligen PIN basierenden Schlüssel-Schutzes lassen sich private Schlüssel vergleichsweise leicht extrahieren
- Das Juicebox-Protokoll dient zum Sichern/Wiederherstellen von Schlüsseln, doch die tatsächliche Sicherheit hängt vollständig vom Vertrauen ins Backend ab, und da Twitter alle Backends selbst betreibt, hat Sharding kaum noch Bedeutung
- Da es kein Out-of-Band-Verfahren zur Authentifizierung/Verifizierung öffentlicher Schlüssel gibt, kann Twitter Schlüssel per MITM (Man-in-the-Middle-Angriff) austauschen, und Nutzer-Metadaten bleiben weiterhin sichtbar
- Anders als bei Signal fehlt derzeit ein wirksamer Schutz der Privatsphäre, daher wird Signal als vertrauenswürdiger verschlüsselter Messenger empfohlen
Analyse von Twitters neuen verschlüsselten DMs
Hintergrund und Zusammenfassung
- Twitter(X) hat die neue verschlüsselte Messaging-Plattform XChat vorgestellt und beworben, sie sei in Rust entwickelt und nutze eine Verschlüsselungsarchitektur im Stil von Bitcoin
- Ein Blick auf die tatsächliche Implementierung zeigt jedoch, dass Twitter weiterhin Zugriff auf private Schlüssel haben, MITM-Angriffe durchführen und Metadaten sammeln kann
- Fazit: Die Nutzung von Signal wird empfohlen, Twitters (X) DMs sind aufgrund grundlegender Einschränkungen nicht sicher
Verschlüsselungsarchitektur und Grenzen
1. Verschlüsselungsverfahren
- Es wird
box von Libsodium (Public-Key-Verschlüsselung) verwendet
- Forward Secrecy wird nicht unterstützt: Wenn ein privater Schlüssel kompromittiert wird, können alle bisherigen Nachrichten entschlüsselt werden (also schwächer als moderne Messenger wie Signal)
- Die tatsächliche Implementierung nutzt nicht Rust, sondern eine C-Bibliothek (über
jni gebunden)
2. Schlüsselspeicherung und Wiederherstellung (Juicebox-Protokoll)
- Auf dem Gerät erzeugte private Schlüssel werden mit dem Juicebox-Protokoll gespeichert
- Die Schlüssel werden nach Verschlüsselung auf Basis einer PIN (4-stellig) gespeichert; zur Wiederherstellung ist die Eingabe der PIN erforderlich
- Der Server kennt die PIN nicht, aber da sie nur 4-stellig ist (10.000 Möglichkeiten), lässt sie sich per parallelem Brute-Force-Angriff schnell knacken
- Selbst mit Argon2id und 16 MB Arbeitsspeicher sowie 32 Iterationen ist das für reale Angreifer kein großes Hindernis (selbst auf einem leistungsschwachen Notebook in unter 0,2 Sekunden)
3. Grenzen der Schlüsselverteilung per Sharding
- Juicebox unterstützt die Verteilung auf mehrere Backends (Sharding), aber Twitter betreibt alle drei Backends selbst
- Am Ende muss man sich bei der Schlüsselwiederherstellung vollständig auf Twitter verlassen, wodurch der grundlegende Sicherheitsvorteil von Sharding entfällt
- Es gibt zudem keine Hardware-Validierungsverfahren wie HSM oder SGX für die sichere Kommunikation mit dem Backend
4. Schwachstellen bei Authentifizierung/Austausch öffentlicher Schlüssel
- Der öffentliche Schlüssel des Gegenübers wird nur über die Twitter-Server bezogen, es gibt keine separate Verifizierungsmöglichkeit (out-of-band)
- Twitter kann daher jederzeit einen beliebigen öffentlichen Schlüssel ausliefern und so einen Man-in-the-Middle-Angriff durchführen
- Auch die offizielle Support-Seite erkennt diese Schwachstelle an und kündigt lediglich künftige Verbesserungen an, ohne konkrete Maßnahmen
5. Metadaten und weitere Probleme
- Metadaten wie wer mit wem wann Nachrichten austauscht, sind für Twitter vollständig sichtbar
- Auch wenn der private Schlüssel nicht offengelegt wird, bleiben die Kommunikationsmuster der Nutzer dem Unternehmen zugänglich
Fazit und Empfehlung
- Wegen der konstruktionsbedingten Grenzen der verschlüsselten DMs erreichen sie in Bezug auf reale Sicherheit und Privatsphäre nicht das Niveau etablierter Messenger wie Signal
- Solange Twitter öffentliche Schlüssel, Keystore und Kommunikationspfade vollständig kontrolliert, kann man nicht von echter End-to-End-Verschlüsselung sprechen
- Die Nutzung eines offenen und transparenten Protokoll-Messengers wie Signal wird nachdrücklich empfohlen
1 Kommentare
Hacker-News-Kommentare
Ich bin ein Fan von allem, was Matthew Garrett schreibt, aber ich möchte hartnäckig darauf hinweisen, dass Signal Forward Secrecy schon seit Langem immer unterstützt hat. Das moderne Konzept sicherer Messenger entstand im Wesentlichen damit, dass OTR (Borisov und Goldberg) als eines der ersten Systeme die Konzepte „perfekte Forward Secrecy“ und Abstreitbarkeit einführte. Signal ist aus meiner Sicht das Ergebnis der Weiterentwicklung sowohl dieser Ideen als auch ihrer technischen Umsetzung (bessere Kryptografie, besserer Code, besseres Packaging). Frustrierend ist, dass neue Messenger nicht nur auf das „Pre-Signal“-Niveau zurückfallen, sondern auf ein Sicherheitsniveau von vor 2001, also vor der modernen Ära
Aus verschiedenen früheren Leaks sollte man sich drei Dinge merken. (1) Das FBI hat Unternehmen „gezwungen“, heimlich Backdoors einzubauen. Es wurde auch erwähnt, dass das FISA-Gericht Firmen mit ruinösen Geldstrafen belegen kann. (2) Großunternehmen wurden für Backdoors mit Summen in zweistelliger Millionen- bis hin zu Hundertmillionenhöhe bezahlt. Außerdem wurde über Regierungsverträge oder Exportlizenzen auf verschiedene Weise Druck ausgeübt. Man kann das letztlich als eine Politik nach dem Muster „Geld oder Waffe“ deuten. (3) Im Fall des Lavabit-Prozesses verlangte das FBI die Herausgabe der Schlüssel und zwang das Unternehmen faktisch zugleich dazu, die Kunden anzulügen. Wenn man sich solche Fälle vor Augen führt, liegt der Verdacht nahe, dass Verschlüsselung auf großen Plattformen auf staatliche Anforderung hin absichtlich geschwächt oder schlicht nachlässig und löchrig umgesetzt wird. Solange Patriot Act, FISC, geheime Rechtsauslegungen und ähnliche Gesetze und Praktiken nicht verschwinden und Verstöße nicht bestraft werden, gilt für mich die Annahme, dass Verschlüsselung im Polizeistaat durch die Five Eyes bereits kompromittiert ist
Solange Leute PC-basierte Apps über den App Store installieren, wird diese rückständige Situation wohl weitergehen
Wenn man einen ephemeral key verwendet, aber weder Forward Secrecy noch einen Nachrichtenverlauf mit Interaktion hat, frage ich mich, was daran wirklich „im Bitcoin-Stil“ sein soll
Kryptografie wird zwar verwendet, aber insgesamt wirkt es wie eine uninteressante und nahezu nutzlose Abspaltung
Soll heißen: praktisch hat das kaum einen Nutzwert
Bitcoin selbst ist ebenfalls kein sicherer Kommunikationskanal
Es gibt wohl eine PIN-basierte Schlüsselableitung. Das wirkt aber eher wie eine Methode zur Umsetzung von Backups als etwas, das dem Messaging selbst eigen ist, und ist daher kaum als wesentliches Merkmal zu sehen
Erwähnt wird auch die Verwendung einer Hash-Funktion
Hier ein Link zu einer früheren Diskussion:
Das neue „verschlüsselte“ XChat von X ist auch nicht wirklich sicherer
Zugehörigen Kommentar ansehen
Wenn man verschlüsseln will, wäre es wohl besser, separate Software zu verwenden und öffentliche Schlüssel persönlich von Angesicht zu Angesicht auszutauschen
Frage: Ich werde bald Peking besuchen und frage mich, ob man Twitter dort ohne VPN nutzen kann
Ich frage mich bei dem Ausdruck „Bitcoin style encryption“, denn Bitcoin basiert nach meinem Verständnis in Wirklichkeit eher auf kryptografischen Signaturen als auf dem, was wir üblicherweise als „Verschlüsselung“ kennen
Der Begriff bedeutet in Wahrheit gar nichts und ist nur ein Marketingausdruck, der für technisch weniger versierte Leute plausibel klingen soll
Man sollte im Kopf behalten, dass die Quelle dieser Aussage selbst technisch nicht besonders tief drin ist
Der Ausdruck wurde verwendet, weil man erwartet hat, dass er Aufmerksamkeit erzeugt. Man kann das als strategische Wortwahl deuten, um mehr Beachtung zu bekommen
Link zu einem Erklärvideo
https://www.youtube.com/watch?v=sJNK4VKeoBM
Einfach ein Schlagwort, das cool wirken und es wie etwas „Wertvolles“ erscheinen lassen soll
Ich frage mich, ob das echte XChat (der IRC-Client) X-Twitter wegen Markenrechtsverletzung verklagen könnte
http://xchat.org/
Ich erinnere mich noch daran, IRC-Nutzer gewesen zu sein, als es früher von XChat zu HexChat überging. Umso überraschender war die Nachricht, dass auch HexChat eingestellt wurde
HexChat-Ende
Wahrscheinlich wäre das möglich, aber XChat müsste für jeden Bereich, in dem X verletzt, die kommerzielle Marktrelevanz gut nachweisen können, und die Marke müsste in den jeweiligen Regionen registriert sein, damit es leichter anerkannt wird. Sonst wird es schwieriger, so die Einschätzung
Interessant an der Bibliothek, die Twitter laut dem verlinkten Artikel verwendet, ist, dass der Entwickler selbst in der Beschreibung der Bibliothek schreibt:
„Warnung: Experimentelle Bibliothek! Bitte nicht in Produktion einsetzen, bevor das Review durch ist. Es gibt erhebliche Risiken und mögliche Bugs.“
https://github.com/ionspin/kotlin-multiplatform-libsodium
Ich staune darüber, dass die Markenmacht von Twitter so stark ist, dass sie selbst nach dem Rebranding noch immer nicht an Zugkraft verloren hat