IOException.de

Icon

Ausgewählter Nerdkram von Informatikstudenten der Uni Ulm

Warum wir eine Wave brauchen

Das Problem

E-Mail ist alt und kaputt. Es gehört durch modernere Kommunikationsarten ersetzt. Warum? Was erwarten wir von Kommunikation über das Internet?

  • Confidentiality, Integrity, Authentication
  • Perfect Forward Secrecy (PFS)
  • Plausible Deniability (PD)
  • Asynchrone und synchrone Kommunikationsmöglichkeit
  • Gruppenkommunikation
  • Kollaboration
  • Multimediale Kommunikation
  • Dezentrale Struktur

Wenn wir von Verschlüsselung sprechen, dann ist damit Ende-zu-Ende-Verschlüsselung gemeint und nicht die Verschlüsselung der Transportwege. Das Gleiche gilt für Integrity und Authentication.

Wir können E-Mails verschlüsseln und digital signieren (z. B. durch Verwendung von OpenPGP). Leider kann dann für immer und von jedem bewiesen werden, dass wir diese Nachricht geschrieben haben. Ein weiteres Problem entsteht, wenn einer der Keys in falsche Hände gerät. Dann sind sämtliche bisher für ihn verschlüsselten Daten kompromittiert.

E-Mail ist langsam und immer asynchron. E-Mail-Verkehr kostet unnötig Zeit.[0]

E-Mail ist nicht kollaborativ.

E-Mail-Anhänge ermöglichen zwar die Übertragung multimedialer Inhalte, sind aber unglaublich ineffizient und ressourcenfressend.

Was gibt es also für Alternativen? Wie kann besser kommuniziert werden?

Soziale Netzwerke sind Privacy-Desaster.

Instant Messaging erfüllt die meisten Zwecke. Bei vielen Protokollen ist sowohl asynchrone als auch synchrone Kommunikation möglich. Confidentiality, Integrity, Authentication, Perfect Forward Secrecy und Plausible Deniability wird durch Verwendung von OTR[1] erreicht (allerdings nur bei Kommunikation mit einem Partner). Einige Protokolle erlauben Gruppenkommunikation durch Chaträume oder multimediale Kommunikation, wie das Übertragen von Dateien oder Video-/Audio-Telefonie.

Warum reichen bestehende Instant-Messaging-Systeme nicht aus? Was fehlt uns?

  • Unterhaltungen in Echtzeit
  • Flexibles Hinzufügen von Teilnehmern zur Gruppenkommunikation
  • Verbessertes Sharing und Darstellung von Multimediainhalten
  • Verschlüsselte, möglicherweise asynchrone, Gruppenkommunikation
    (mit PD und PFS)

Die ersten drei Punkte kann Googles Wave[2,3]. Das Problem der verschlüsselten Gruppenkommunikation mit den beschriebenen Bedingungen ist leider darin bisher nicht gelöst worden. Zudem existieren keine zufriedenstellenden Clients für Wave.

Wir wollen, dass die Infrastruktur nicht von einem einzigen Knotenpunkt abhängig ist. Dezentrale Struktur wird von den Protokollen, die E-Mail bzw. Wave zugrunde liegen, unterstützt. Fast alle IM-Dienste erlauben diese nicht.

Die Lösung

Wir sehen mehrere Lösungsansätze.

Komplett neues Protokoll mit Implementierung und Infrastruktur

Auch bekannt als: „Das Rad neu erfinden“. Machen wir nicht. Das Rad gibt es schon. Dieser Ansatz wäre sehr aufwändig und würde sich schwer etablieren.

Verwendung bestehender Protokolle

Bedingung ist, dass das Protokoll offen und leicht erweiterbar ist. Hier halten wir nur XMPP für sinnvoll. Der Vorteil dieser Lösung ist, dass genau die gewünschten Features implementiert werden können und keine Kompromisse notwendig sind. Voraussichtlich wird bereits bestehende Infrastruktur verwendet werden können.

Erweiterung von Wave

Wave hat bereits die meisten Features, welche wir uns wünschen. Verschlüsselung fehlt aber und es existieren keine guten Clients.

Der Plan

Wir evaluieren die letzten beiden Lösungsansätze und implementieren dann die sinnvollste Lösung. Dazu müssen wir zunächst XMPP und das Google Wave Federation Protocol verstehen.

Auf jeden Fall werden wir einen Client schreiben, der im Vergleich zu bestehenden Clients besser bedienbar ist und unsere beschriebenen Anforderungen erfüllt. Für Legacy-Clients ist eine (teilweise) Umsetzung der Features, beispielsweise durch Plugins, denkbar.

Die Unzufriedenheit mit vorhandenen Kommunikationsmöglichkeiten und die Idee diese zu verbessern schlummert schon seit einiger Zeit in uns. Hiermit möchten wir die Sache ins Rollen bringen. Stay tuned!

–nico, phil, matou

[0] http://www.heise.de/newsticker/meldung/Unternehmen-will-Mitarbeitern-die-E-Mail-abgewoehnen-1184596.html
[1] http://www.cypherpunks.ca/otr/
[2] http://wave.google.com/
[3] http://www.waveprotocol.org/

Kategorie: security, web, xmpp

Tags: , , , , ,

Diese Icons verlinken auf Bookmark Dienste bei denen Nutzer neue Inhalte finden und mit anderen teilen können.
  • MisterWong
  • Y!GG
  • Webnews
  • Digg
  • del.icio.us
  • StumbleUpon
  • Reddit
  • Facebook

4 Kommentare

  1. Stefan sagt:

    Die Aussage, daß bei PGP “für immer und von jedem bewiesen werden (kann), dass wir diese Nachricht geschrieben haben”, ist nicht korrekt. Das gilt nur bei Nachrichten, die nur signiert sind – und dort ist das ja auch Sinn und Zweck der Übung. Versendet man mit PGP signiert+verschlüsselte Nachrichten, so wird _zuerst_ die Signatur erzeugt und _anschließend_ das gesamte Paket verschlüsselt. Die Signatur ist somit nur von den Empfängern überprüfbar. Bei S/MIME sieht es anders aus, da ist die Reihenfolge genau umgekehrt.

    Ich sehe mit PFS/PD zwei Probleme:
    1. Bei der asynchronen Kommunikation müßte ich das temporäre Schlüsselmaterial zwischenspeichern, sonst funktioniert das nicht. Ein neuer Teilnehmer, der (asynchron) dazustößt, könnte knifflig werden (key scheduling), aber eventuell findet man da eine Lösung.
    2. Ich will meine Mails archivieren, und die Archiv-Anforderung hätte ich auch an ein neues System. Klar kann ich die Daten einfach entschlüsselt ablegen, aber dann ist euer Argument mit dem Schlüssel in falschen Händen mehr oder minder hinfällig :-) Gerade Firmen haben strenge Auflagen was die Archivierungspflichten von Mails angeht; und gerade da sehe ich die Notwendigkeit, daß zumindest Signaturen beim Archivieren erhalten bleiben müssen.

  2. Seb sagt:

    Hier noch eine Website die Eure These unterstützt:

    http://www.e-fellows.net/show/detail.php/23869?utm_campaign=nlme1111&utm_content=&utm_medium=em&utm_source=nl

    Auch Firmen dürften an solch einem System sehr interessiert sein.

  3. matou sagt:

    @Stefan:
    Das stimmt. Bei der verschlüsselten Gruppenkommunikation gibt es eine ganze Reihe von Problemen, die bisher nicht zufriedenstellend gelöst sind. Dass Leute ihre Nachrichten eventuell mit Signatur archivieren wollen sollte kein Problem sein. Niemand wird schließlich daran gehindert seine Nachricht zusätzlich zu signieren. Für normale Unterhaltungen möchte ich aber nicht, dass später festgestellt werden kann, dass tatsächlich ich diese Sachen gesagt habe.
    Und im Vergleich dazu, dass die Firma in dem Heise-Artikel Soziale Netzwerke zur Kommunikation verwenden will, halte ich unsere Überlegungen für deutlich sinnvoller (-;

  4. matou sagt:

    @Seb:
    Vielen Dank für den Link. Es macht mir etwas Angst, dass die ganzen Firmen auf Social Communities gehen. Man KANN es schon richtig machen. Aber wir wissen ja, dass es mit den bestehenden Netzwerken oft große Probleme gibt.

Kommentar