The Free Haven Project

Einführung

Das Ziel des Free Haven Projektes war es, ein Design für ein verteiltes anonymes Speichersystem zu erstellen. Dieses soll robust gegen Angriffe auf Anonymität und Verfügbarkeit von Dokumenten sein. Das Free Haven Projekt ist fehlgeschlagen. Sicherzustellende Anonymitäten und Robustheit gegen Angreifer konnten nicht verwirklicht werden, weil sie gegensetzliche Forderungen hatten: Robust gegen Angreifer nur durch viele Benutzer, System allerdings bei vielen Servern und Benutzern nicht skalierbar.

Akteure, System, Begriffe

Die Akteure in diesem System sind:

• Autor - Der Autor will Daten für andere verfügbar machen ohne seine Identität zu veröffentlichen.
• Veröffentlicher - Der Veröffentlicher ist ein System welches Daten im Servnet verfügbar macht ohne die zu veröffentlichten Daten oder den Autor zu kennen.
• Leser - Der Leser kennt Daten unter einem bestimmten Pseudonym und will diese vom System erhalten.
• Server - Der Server gibt eigenen Speicher frei und stellt dort Dokumentanteile bereit.

Dabei befinden sich die Akteure Server und Veröffentlicher befinden sich in der Regeln innerhalb des sogennanten Servnets. Free Haven fordert, dass dies ein dynamisches Netz ist, dies bedeutet, dass ein Server in des Servnet ein- und austreten kann.

Überblick Servnet

Kommunikationskanäle

Wie in der Abbildung gezeigt kommunizieren alle Teilnehmer über sichere Kommunikationskanäle. Das bedeutet, dass die Kommunikation nur indirekt über ein sogenannten Remailer erfolgen kann.

Free Haven benutzt dabei den sogenannten Cypherpunk Remailer Dienst.

Beispiel eines sicheren Kommunikationskanals

Die Kommunikation erfolgt indirekt über den Cypherpunk Server. Der Benutzer kodiert die an den SN gerichteten Daten mit dem SN eigenen Schlüssel, damit auch der Remailer keinen Einblick in die übermittelten Daten hat und so dem Benutzer bestimmte Daten zuordnen könnte. Damit der Remailer weiß an wen er die Daten weiterzuleiten hat, gibt der Benutzer den Reply Block des Servers an, der zusammen mit seinem Pseudonym veröffentlicht wurde. Der Reply Block enthält dann die IP des zu erreichenden Servers, allerdings so verschlüsselt, dass nur der Remailer diese ermitteln kann. Der Remailer sendet dann die Daten an den Server. Auf diese Weise erhält der unter dem Pseudonym bekannt SN die Daten des Benutzers ohne dass er die Identität des Benutzers erfahren hat. Gleichzeitig kann der Remailer die Daten dem Benutzer nicht zuordnen, da sie mit dem öffentlichen Schlüssel des Servers verschlüsselt wurden.

Dieser Kommunikationskanal ermöglicht also eine anonyme Kommunikation.

Anwendungsfälle

Publication

Der Veröffentlichungsvorgang verläuft kann in zwei Arten erfolgen: Entweder der Veröffentlicher selbst sorgt für die notwendige Verarbeitung der zu veröffentlichen Datei oder ein Publisher übernimmt diese Rolle. Grundsätzlich müssen folgende Dinge beim Veröffentlichen geschehen:

• Die Datei wird mit einem asymmetrischen Schlüsselpaar verschlüsselt, welches nur der Autor kennt.
• Die verschlüsselten Daten werden dann mittels des Information Dispersal Algorithmus in mehrere Teile geteilt.
• Jedes dieser Teile wird mit einer Signatur und den notwendigen Informationen zum späteren Zusammenbauen bestückt. Desweiteren bestimmt der Autor ein Gültigkeitsdatum, welches definiert wie lange dieses Dokument bzw die einzelnen Shares von den Servnet Nodes gespeichert werden soll. Die Gesamtheit dieser Informationen und einem Teil wird als "Share" bezeichnet.
• Diese Teile werden entweder direkt an verschiedene Servnet Nodes getauscht oder auf dem eigenen Speicher (im Falle, dass der Publisher selbst Servnet Node ist) gespeichert.

Zur Identifikation des Shares wird der öffentliche Schlüssel verwendet. Das bedeutet, dass der Server bei einer Anfrage eines öffentlichen Schlüssels seine Shares durchsucht. Die Suchanfrage ist dabei der Hashwert des gesuchten Schlüssels um Query Anonymity zu garantieren.

Bemerkung: Es ist möglich, dass die Shares nicht anhand des öffentlichen Schlüssels identifiziert werden, sondern anhand des Hashwertes des öffentlichen Schlüssels. Dies würde eine erhöhte Server Anonymity bieten. Der Server wäre sonst in der Lage selbst eine Anfrage in das Servnet zu stellen und kann so das Dokument herstellen, für das sein Share steht! Dies hätte aber auch zur Folge, dass es keine Möglichkeit mehr gibt "illegale" Daten zu veröffentlichen, aus diesem Grund wird in der Regel nicht nur der Hashwert gespeichert.

Retrieval

Bei einer Anfrage eines Readers werden folgende Dinge gesendet:

• Reply Block des Readers, um dem Server die Möglichkeit zu geben, dem Reader über einen anonymen Kommunikationskanal zu erreichen.
• Öffentlicher Schlüssel des Readers.
• Der Hashwert des öffentlichen Schlüssels, welches der Reader sucht.

Diese Anfrage sendet der Reader über einen Reply Block an ein Servnet Node. Die Anfrage wird dabei mit dem öffentlichen Schlüssel des Servnet Nodes verschlüsselt, so dass der Remailer nicht nachvollziehen kann was der Reader gesucht hat. Der Servnet Node wiederum kann nicht feststellen, wer die Anfrage gestellt hat.

Ein Servnet Node empfängt eine solche Anfrage und durchsucht daraufhin die Liste seiner Shares. Besitzt er ein entsprechendes Share verschlüsselt er dieses mit dem öffentlichen Schlüssel des Readers und sendet dieses an den Reply Block des Readers. Der Remailer ist wiederum nicht in der Lage das Share zu lesen, da nur der Reader den zugehörigen privaten Schlüssel besitzt.

Danach sendet der Servnet Node die Anfrage per Broadcast an alle ihn weiter bekannten Servnet Nodes. Außerdem merkt sich der Servnet Node diese Anfrage, damit er sie nicht doppelt berarbeitet.

Expiration

Läuft die Gültigkeit einzelner Shares ab, so kann der Server diese kommentarlos löschen.

Trading

Der zentrale Vorgang der Servnet Nodes ist das Trading. Dieser Vorgang bezeichnet das Tauschen von Shares.

Wichtig ist dieser Vorgang um Server Anonymity zu garantieren: Wenn ein Share permanent nur auf einem Server verfügbar wäre, so könnte man diesem Server unterstellen zu wissen was er teilt. Weiterhin soll das Servnet dynamisch sein, d.h. Servnet Nodes sollen sich vom Servnet Abtrennen und Anschließen können. Mittels Trading könnten Servnet Nodes ihre Shares gegen kurzlebige Shares tauschen und auf den Ablauf dieser warten. Sobald der Servnet Node keine Shares mehr besitzt kann er sich legal (ohne Reputationsverlust) Abschalten.

Problematisch ist, dass dieser Vorgang Fläche für viele Angriffe bietet.

TODO

Revocation

Es gibt die Möglichkeit Dokumente zurückzurufen. Dafür muss bei der Veröffentlichung ein neues Feld in die Shares eingebaut werden. Dieses enthält den Hashwert eines Geheimnisses des Autors. Möchte der Autor ein Dokument zurückrufen authentifiziert er sich durch dieses Geheimnis. Die Servnet Nodes dürfen daraufhin die dazugehörigen Shares löschen. Die Veröffentlichung des Geheimnisses passiert wieder per Sendung an ein Servnet Node, der wiederum einen Broadcast dieses Zurückrufs sendet.

Angriffe

TODO

Problem

Bei zu geringer Teilnehmeranzahl kann nicht garantiert werden, dass die Dokumente dauerhaft im Servnet gespeichert werden, da Angreifer leicht gezielt Dokumente zerstören können.

Bei zu hoher Teilnehmeranzahl ist die Performanz des System niedrig (das System ist nicht skalierbar). Dies liegt vor allem an den Broadcasts innerhalb des Servnets.

Diese gegensätzlichen Ziele führten zum Abbruch des Projekts.

Quellen

• D. M. Roger Dingledine, Michael J. Freedman. The Free Haven project: Distributed anonymous storage service. In Proceedings of the Workshop on Design Issues in Anonymity and Unobservability, July 2000. http://citeseer.ist.psu.edu/article/dingledine00free.html
• R.R. Dingledine, "The Free Haven Project: Design and Deployment of an Anonymous Secure Data Haven," M.Eng. thesis, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology (2000). Available at http://www.freehaven.net/ (2000). http://citeseer.ist.psu.edu/dingledine00free.html
• Michael O. Rabin, "Efficient dispersal of information for security, load balancing, and fault tolerance, April 1989.