Free Haven

Einführung

Das Free Haven Projekt zielt darauf ab ein System für verteilten, anonymen und persistenten Datenspeicher anzulegen, welches robust ist gegenüber Versuchen "böser" Nutzer jedwede Daten zu finden und zu zerstören. Das ursprüngliches MIT-Projekt und Master-Thesis von R.Dingledine (Projektleiter in Tor, Mitentwickler Mixminion) und einiger anderer Studenten wurde jedoch aufgrund veschiedener ungelöster Probleme auf Eis gelegt.

Roger Dingledine

System Design

• Kommunikationskanal
  • Für anonyme und vertrauliche Kommunikation
• Publicationssystem
  • Zum Speichern und Bereitstellen von Daten und Dokumenten
• Agenten / Benutzer
  • Autoren, Leser, Server
  • Kommunikation via Reply-Blocks über Comm. Channel
• Operationen
  • Publication System stellt Operation die von den Agenten benutzt werden
  • Simple Operationen wie Einfügen und Lesen
  • Komplexere Operationen wie Handel oder Vertrauens-System

Einführung

Das gesamte ist in einer Community von Servern angeordnet - das Servenet. Dabei hat jeder Server einen eigenen Public-Key, wie auch Reply-Blocks und die Informationen über die entsprechenden Keys und Blöcke der anderen Server. Daten werden in Stücke zerteilt und auf den einzelnen Servern untergebracht. Die "Autoren" fügen dem ganzen ein Ablaufsdatum hinzu und die Server versprechen dieses einzuhalten. Kontrolliert wird das ganze von einem globalen Trust-System.

Struktur eines Free Haven Servers

• Haven Modul

Kontrolliert wird der Server über das Haven Modul. Dieses beinhaltet das Trust- und das Trading-Modul

Haven Modul ist wichtig für viele Operationen des Systems als ganzen und u.a. zuständig für:

• Dokumente speichern, bereitstellen, ablaufen lassen.
• Handelsanfragen bearbeiten
• In-/Aktive Server verwalten
• Trust-Broadcasts & Buddy-Checking

• Komm Modul

zuständig für Kommunikation zwischen Servern (momentan durch mixnet implementiert (kann ausgetauscht werden)

• Node DB

Haven- und das Kommunikationsmodul reden mit der Node Datenbank. Diese ist ein Datenbank über andere Server und Shares ZB für Anfragen nach

• Mit mixnet assoziierte Adresse eines Public-Keys
• Servern mit shares einer bestimmten Grösse
• Vertrauenswürdigen Servern

Alle drei Module können auch auf jeweils seperaten Servern laufen.

Operationen

Die zwei wichtigsten operationen im netzwerk sollen kurz vorgestellt werden.

• Hinzufügen von Dokumenten

Zuallererst brauchen wir einen Node der die Datei speichern will. Das sind entweder wir selber oder wir finden einen Node über gespeicherte ReplyBlocks aus Listen im Internet. Dann verschicken wir das Dokument zB. über einen anonymen Remailer. Der Server teilt dieses dann in einzelne shares auf und fängt an sie mit anderen Servern zu handeln. (Das ganze natürlich noch über private/public Keys - genaueres dazu im Paper)

• Abrufen von Dokumenten

Nachdem wir den Public Key des gewünschten Dokuments besitzen (Listen,Fore, etc.), schicken wir eine Anfrage mit dem Key und unserem ReplyBlock an einen Servenet Server. Der Servenet-Server schickt die Anfrage an alle bekannten Nodes etwa in folgender Art: ('request', PK_file, PK_client, ReplyBlock) Jeder Server der die Anfrage bekommt schickt die shares, so vorhanden, per ReplyBlock raus. Sind dann genügend shares eingetroffen kann das Dokument wieder zusammengefügt werden.

Handel von „shares“

Shares werden aufgrund der Währung "Größe*Lebensdauer" gehandelt. durch den Handel sind erstens Anonymität, Dynamik und Sicherheit gewährleistet. Ausserdem ist dadurch einfach eine längere Lebensdauer der shares möglich. Will Server A nun also handlen passiert folgendes:

• Sucht er sich einen Server B aus seiner Liste bekannter Server raus (basierend auf „Trust“ und bisherigen Handelsaktionen)
• Bietet B einen share Фi an, sowie Informationen was A gerne für shares haben möchte
• Ist B einverstanden bietet es einen share λk zurück
• Die Verhandlung ist mit einer Zustimmung beider Seiten beendet (inklusive einer Quittung)
• Anschliessend werden die shares ausgetauscht

Das ganze wird wie gesagt quitiert. Dabei ist dies jedoch nicht direkt als Beweis für Transaktionen zu sehen, vielmehr als Indiz für die Verpflichtung einen gewissen share zur Verfügung zu halten, damit das „Trust“-System bei Fehlverhalten darauf reagieren kann.

Schlussbetrachtungen

Die Weiterentwicklung wurde wie schon erwähnt aufgrund einger grosser Probleme auf Eis gelegt.

1. Das Reputationssystem ist kompliziert, schlecht anwendungsfähig und müsste durch ein besseres und robusteres ersetzt werden
2. Datenrückgewinnung läuft momentan durch Broadcasts was so nicht tragbar ist. Gehashte Adressen wäre zB eine Möglichkeit
3. Es gibt keine anonymen Kommunikationsstrukturen. Auf diesem Gebiet wird immer noch geforscht.

Referenz

• Free Haven's site
• Tor

Roger Dingledine.

The Free Haven Project: Design and Deployment of an Anonymous Secure Data Haven.

MIT Master's Thesis, June 2000.

Michael O. Rabin

Efficent dispersal of information for security, load balancing and fault tolerance,

April 1989