Secure-Messaging-Systeme sind anfällig für Metadaten-Analysen, also für die Informationen darüber, wer wann mit wem kommuniziert. Seit wir wissen, dass die „Five Eyes“-Geheimdienste in großem Umfang und international die Netzwerke überwachen, suchen Aktivisten und Forscher nach Lösungen, um die Analyse der Metadaten zu unterbinden. Für den Messenger „Vuvuzela“ wurde ein Konzept entworfen, dass es Dritten unmöglich macht, die Metadaten der Nutzer zu analysieren.
Wir sprachen mit David Lazar, der einer der vier Personen ist, die Vuvuzela konzeptioniert und vorgestellt haben. David selbst schreibt den Code, der im github-Repository zu finden ist.
Es gibt auch eine englische Version dieses Interviews.
Die Idee
In Vuvuzela wird Noise erzeugt, also eine Art Rauschen, um Angreifer wie die „Five Eyes“-Geheimdienste daran zu hindern, die Metadaten der Benutzer abzugreifen. Verschlüsselung allein kann nicht verhindern, dass die Menge der inaktiven oder der gerade kommunizierenden Benutzer und deren Interaktionen überwacht und analysiert werden kann. Daher wird zusätzliches Rauschen erzeugt, um die Metadatenanalyse ressourcenstarker Angreifer zu vereiteln und um zu verschleiern, wer wann mit wem spricht. Vuvuzela-Server erzeugen dieses Rauschen und bieten damit Schutz vor Verkehrsanalysen.
Es gibt bereits einige Ansätze für sichere Messenger, die sich am Metadatenschutz versuchen. Pond ist dafür ein Beispiel, aber auch das schon vor einigen Jahren vorgestellte Konzept von Dissent (pdf).
Das Vuvuzela-Konzept (pdf) wurde im Oktober 2015 von Jelle van den Hooff, David Lazar, Matei Zaharia und Nickolai Zeldovich beim 25. ACM Symposium on Operating Systems Principles vorgestellt.
Vuvuzela consists of a single chain of servers to which clients connect to communicate. We assume that the chain of servers, along with each server’s public key, is known to clients ahead of time; all clients use the same chain. Clients always connect to the first server in the chain, which in turn connects to the second server, and so on.
Vuvuzela clients participate in two protocols. The first protocol, called the conversation protocol, allows a pair of users to exchange messages, assuming that they both decided to communicate with one another. The second protocol, called dialing, allows one user to request a conversation with another.
Interview mit David Lazar
Im Gegensatz zu anderen Ansätzen zum Schutz der Metadaten, wie beispielsweise beim Tor-Projekt, kommen bei Vuvuzela auch Techniken zum Einsatz, die ein Rauschen erzeugen, um Angreifer abzuwehren, die das Netzwerk zur Metadatenanalyse beobachten. Warum wurde dieser Ansatz gewählt?
Wir haben das System so entworfen, dass wir versuchen, möglichst viele Metadaten effizient zu verschlüsseln. Allerdings gibt es einige Metadaten, die wir nicht effizient verschlüsseln können. Wir fügen daher unverschlüsselten Metadaten ein Rauschen hinzu, so dass deren Bedeutung für einen Angreifer verschleiert wird.
Effizienz war schon von Anfang an eines unserer Ziele. Wir fanden, dass das Hinzufügen von Rauschen eine ziemlich gute Effizienz und ziemlich gute Sicherheit zugleich bringt.
Wäre ich ein Beta-Tester, was kostet mich dieses Rauschen beim Dialing-Protokoll an Serverbandbreite?
Jeder Nutzer braucht etwa 12 KB/s an Bandbreite, um den Vuvuzela-Client auszuführen. 12 KB/s ist viel, wenn man den Vuvuzela-Client auf einem Telefon laufen lassen will. Wir denken daher über Möglichkeiten nach, die Client-Bandbreite zu senken.
Die zwei Protokolle von Vuvuzela kommunizieren über sog. „dead drops“, über die ein Nutzer eine Nachricht hinterlassen und ein anderer Nutzer sie abholen kann. Wird es in Zukunft ein CDN (Content Delivery Network) für die Verteilung der „dead drops“ geben?
Ja. Unser derzeitiger Plan sieht vor, BitTorrent zu verwenden, um die dead drops zu verteilen, aber wir haben das bisher noch nicht implementiert.
Wann wird die Implementierung denn beginnen?
Uns hindern derzeit noch zwei Dinge am Ausrollen von Vuvuzela: Erstens gibt es noch keine PKI [Public Key Infrastructure], zweitens fehlt uns noch ein guter Weg, die dead drops zu verteilen. Ich habe bereits begonnen, an der PKI zu arbeiten, und ich gehe davon aus, dass wir BitTorrent integrieren, nachdem wir die PKI fertighaben.
Wir haben auch eine gewisse Hoffnung, dass wir ein effizienteres Dialing-Protokoll zur Signalisierung entwerfen können, so dass wir kein CDN oder BitTorrent dafür brauchen.
Als Beta-Tester kann ich derzeit nur die pki.conf nutzen?
Ja. Dann müssen die Schlüssel aber über einen anderen Kanal mit den Kommunikationspartnern ausgetauscht werden.
Aus der Sicht des Benutzers: Wenn ich ein Gespräch beginnen möchte, wird für jede Kommunikation erneut das Dialing-Protokoll gestartet, richtig?
Richtig. Wenn Alice mit Bob reden will, dann tippt sie /talk bob gefolgt von /dial bob, danach wird Bobs Client signalisiert, dass Alice ihn gern sprechen würde. Wenn Bob das auch will, tippt er /talk alice ein, dann kann das Gespräch losgehen.
Der öffentliche Schlüssel von Alice wird dabei an Bob übertragen werden, dann ein gemeinsames Geheimnis berechnet, das Dialing-Protokoll zu allen Kommunikationspartnern muss aber für jedes Gespräch neu initiiert werden?
Richtig. Derzeit brauchen aber Alice und Bob noch gegenseitig ihre dauerhaften Schlüssel aus der pki.conf, um zu gewährleisten, dass sie mit der richtigen Person sprechen. In der Zukunft wird eine bessere PKI diesen Prozess nutzerfreundlicher machen.
Wird das vergleichbar nutzerfreundlich sein wie bei OTR oder GnuPG?
Ja. Im Idealfall wäre es sogar noch benutzerfreundlicher. :)
Du hast auch zu benutzerfreundlichen Systemen geforscht. Betrachtest Du die Benutzerfreundlichkeit als wichtig?
Ich denke, die Benutzerfreundlichkeit ist überaus wichtig. Wenn ein System nicht benutzerfreundlich ist, dann wird es niemand nutzen, und das ist zugleich schlecht für die Sicherheit.
Wenn man auf Benutzerfreundlichkeit setzt, könnte das für Vuvuzela ein Vorteil gegenüber anderen sicheren Messengern sein, um viele Nutzer zu finden, weil es eben nicht nur sicher, sondern auch angenehm verwendbar ist?

Ich denke, dass es natürlich toll wäre, wenn Nutzer wegen der Benutzerfreundlichkeit Vuvuzela wählen, nicht nur wegen der Sicherheit. Aber wir sind davon noch ein ganzes Stück entfernt.
Benutzerfreundlichkeit bringt oft Kompromisse mit sich, weil Benutzer – absichtlich oder ohne es zu wissen – die Sicherheit durch ihr Verhalten kompromittieren können. Wie geht ihr mit diesem Problem um?
Das ist ein nicht-triviales Problem. Ein Ansatz wäre zu versuchen, eine ziemlich gute Sicherheit standardmäßig anzubieten (ohne dass der Nutzer einen Aufwand hat), gleichzeitig aber die Möglichkeit zu lassen, eine wirklich wasserdichte Sicherheit mit einigem Benutzeraufwand zu konfigurieren (zum Beispiel, indem der Nutzer die Schlüssel seiner Freunde manuell überprüfen kann).
Ich denke, Signal versucht es mit diesem Ansatz.
In dem Konzept-Papier für Vuvuzela wird die Idee beschrieben, die Nutzer selbst als „Rauschen“ zu verwenden, wenn es viele davon gibt. Wie stark könnte das die bisher hohe Bandbreite reduzieren?
Das ist noch nicht klar. Vielleicht können wir das meiste Rauschen loszuwerden, wenn es eine große Menge an Nutzern gibt, aber derzeit wird die Bandbreite noch von Nutzer-Nachrichten dominiert (also nicht durch Rauschen).
Wann wird ein Nutzer-Client fertig sein, und wann wird die Software für die allgemeine Verwendung ausgerollt?
Das Ausrollen ist für die erste Hälfte dieses Jahres geplant.
Es gibt mittlerweile eine ganze Menge neuer Krypto-Messenger, seit den Enthüllungen von Edward Snowden hat die Anzahl nochmal zugenommen. Ist die Entwicklung von „Vuvuzela“ eine Reaktion auf Snowdens Enthüllungen, grade weil auch der Schutz von Metadaten umfasst ist?
Snowdens Enthüllungen hat unsere Arbeit angeregt, aber wir finden auch das Problem der Verschleierung von Metadaten einfach interessant und herausfordernd.
Würdest Du soweit gehen zu sagen, dass eine Art Wettrüsten zwischen der NSA (inklusive „Five Eyes“), die Metadaten in großem Umfang sammelt, und Aktivisten und Forschern wie Euch, die sichere Systeme wie Vuvuzela entwerfen, im Gange ist?
Wenn es ein Wettrüsten gibt, dann glaube ich, dass wir es verlieren werden, wenn wir uns nicht auf Benutzerfreundlichkeit konzentrieren.
Zuletzt: Ich muss die Frage loswerden, auch weil es vermutlich jeder wissen will: Wie kamt ihr auf Vuvuzela als Namen, wo doch jeder damit schreienden Lärm verbindet?
Das System macht eben eine Menge „Noise“, also dachten wir, Vuvuzela wäre ein passender Name. :)
David, vielen Dank für die Beantwortung der Fragen!
Wenn jemand von Euch Lust hätte, einen Vuvuzela-Server in Deutschland oder anderswo in Europa zu betreiben, meldet Euch bitte bei constanze(at)netzpolitik.org.
Transkribierung, Bearbeitung and Übersetzung: Constanze, Simon und Jakob.
Das Konzept sieht viel versprechend aus. Wenn das gesamte Team so sauber denkt und handelt wie David, dann hat der „Vuvuzela Messenger“ eine echte Chance sich zu etablieren. Leider sind die Menschen Gewohnheitstiere und es gibt schon viele Messenger unterschiedlichster Art, die bereits länger fungieren. Wenn irgend wann die finale Version fertig ist, bekommt die Überzeugungsarbeit an zukünftigen Nutzern das größte Gewicht. Benutzerfreundlichkeit ist tatsächlich die alles entscheidende Instanz noch vor der Sicherheit. Beides zusammen wäre optimal für den Erfolg.
mfg R.K.
Ist von der Funktionsweise ähnlich wie das Qabel-Projekt, welches mir aber bislang als die einzig vernünftige Lösung erscheint, da vielseitiger.
https://qabel.de/files/2015-03-11_qabel_fact-sheets_de.pdf
„Wird das vergleichbar nutzerfreundlich sein wie bei OTR oder GnuPG?“
Echt jetzt? Oder entgeht mir da hammerharte Ironie? Ich selbst nutze PGP bzw. GPG seit Ende der 90er, und seit dieser Zeit bin ich auch als Prediger durch die Wüste gezogen, um andere davon zu überzeugen. Mit extrem wenig Erfolg – die Angelegenheit ist für Normalnutzer einfach viel zu sperrig, zumindest wenn es um E-Mails geht (die Kontalk-Entwickler haben die bittere PGP-Pille tatsächlich unauffällig verpackt). Und das gilt selbst heute noch, trotz der fabelhaften Arbeit des Enigmail-Projekts.
Dasselbe gilt natürlich für OTR. Via XMPP/OTR kommuniziere ich bestenfalls mit einem kleinen technikaffinen Grüppcchen.
Hört sich super an. Was sind die Unterschiede zu und die Gemeinsamkeiten mit Bitmessage und I2P-Bote?
Bitmessage ist doch schon perfekt eigentlich. Man könnte noch einen Bloomfilter wie beim Bitcoin Client einbauen, damit das ganze Konzept auch skalliert. Durch den Bloomfilter hat man noch entsprechend viel rauschen, aber eben garantiert auch alle Messages die einem zugestellt werden sollen.
Man gibt einfach seine Filtermaske an fremde Clients raus. In der Filtermaske sind alle Bits 1 die eigene Adressen betreffen + ein paar Randombits um keine Clientidentifizierung durch selbe Masken zu ermöglichen. Der Peer antwortet dann mit einer Maske welche Bits er bedienen kann (AND mit der eigenen Makse). Man muss dann halt so lange zu weiteren Peers verbinden bis man für Alle Maskenbits der eigenen Maske eine Quelle hat.
Die Maskengröße würde man je nach Netzwerkgröße varriieren.
Bitmessage ist zu empfehlen, da es vollständig dezentral ohne Server funktioniert und dazu metadatenfrei und nach außen anonym ist. Es basiert auf der Blockchain-Technologie. Alle Nachrichten gehen an alle, aber nur die Empfängerinnen können sie lesen, weil sie verschlüsselt sind. Es ist sehr ähnlich wie Email in der Nutzung, Mailinglisten sind auch möglich.
Bitmessage lässt sich auch hinter Tor betreiben, um noch das einzige Metadatum neben der Internetaktivität, nämlich den Bitmessage-spezifischen Traffik, zu verscheiern.
Es ist bislang beta und benötigt noch Codereviews, um vollständig von der Cryptoszene akzeptiert zu werden.
Naja, jede der bitmessage-Adressen ist öffentlich verfügbar, mit einem Skript aus messages.dat auslesbar. Und bitmessage skaliert einfach nicht.
Srsly? Neben Constanze steht „Autor“? Bug oder Feature?
(Da haben sich die ganzen Diskussionen über das Binnen-I in den letzten Monaten in NP-Kommentarspalten echt gelohnt lol)
Einen Vuvuzela Server zu betreiben wird ein teuerer Spaß sein, wenn Vuvuzela in dem Maß benutzt werden wird, wie in dem Paper angenommen. In dem Paper las es sich so, dass die Kette von Vuvuzela Servern fest ist. Viele können es – vorerst – auch nicht sein. Weitergehende Forschung wird zwar eine mögliche Dezentralisierung beleuchten, momentan wären diese wenigen Server aber ein lohnendes Angriffsziel.
Dezentralisierte Systeme scheinen mir auch interessanter zu sein. Leider gibt es momentan noch kein brauchbares. „Bitmessage ist zu empfehlen“ ist eine gefährliche Aussage, solange man nicht weiß wie die Gefährdung des Benutzers aussieht.
Bitmessage ist interessant, aber einem Whistleblower würde ich es z.B. nicht empfehlen. Dafür gibt es noch zu viele offene Punkte. Die benutzten Kurven sind unsicher, forward secrecy ist nicht implementiert, und es ist nicht robust gegenüber byzantinischen Fehlern, wie es z.B. gerade bei GNUnet versucht wird (https://gnunet.org/brahms) robust dagegen zu sein.
@Constanze „jede der bitmessage-Adressen ist öffentlich verfügbar, mit einem Skript aus messages.dat auslesbar“ Warum ist jede aus message.dat auslesbar? Was kann man damit anfangen? Bitmessage skaliert angeblich über sogenannte Streams. Habe noch nichts darüber gelesen, ob das funktioniert oder nicht. Soweit ich weiß gibt es momentan nicht so viele Bitmessage Nutzer, dass es ein Problem darstellt.