Systems Architecture Free Haven Project Gerd Wittchen, Christopher Rudolf 19.06.2007.

Präsentation zum Thema: "Systems Architecture Free Haven Project Gerd Wittchen, Christopher Rudolf 19.06.2007."—  Präsentation transkript:

1 Systems Architecture http://sar.informatik.hu-berlin.de Free Haven Project Gerd Wittchen, Christopher Rudolf 19.06.2007

2 2 May 2006 - 2 Systems Architecture http://sar.informatik.hu-berlin.de  Verteilte Speichersysteme und Anonymität  Hash, Signaturen, Asymmetrische Verschlüsselung  Free Haven Project - Begriffe, Akteure, Systeme, Ablauf - Kommunikationskanäle - Anwendungsfälle - Publication - Retrieval - Expiration - Revocation - Trading  Angriffe auf Free Haven und Probleme  Zusammenfassung / Diskussion Überblick

3 3 May 2006 - 3 Systems Architecture http://sar.informatik.hu-berlin.de Verteilte Speichersysteme und Anonymität P2P2 Download erfolgt direkt vom Datenanbieter (P2P). ►Anonyme Speichersysteme können keine direkte Verbindung zwischen Autor und Leser zulassen. Welche Alternativen gibt es? Usene t

4 4 May 2006 - 4 Systems Architecture http://sar.informatik.hu-berlin.de Verteilte Speichersysteme und Anonymität Was bedeutet Anonymität? Autor veröffentlicht Daten. Identität des Autors bleibt geheim. Daten und Autor sind nach Veröffentlichung nicht zuordenbar. ►Author Anonymity Author Democracy is the best kind of government.

5 5 May 2006 - 5 Systems Architecture http://sar.informatik.hu-berlin.de Verteilte Speichersysteme und Anonymität Was bedeutet Anonymität? I want to have XYZ. Reques t Der Server weiß nicht, wonach der Anfragende sucht. Der Server weiß nicht, wer der Anfragende ist. ►Query Anonymity

6 6 May 2006 - 6 Systems Architecture http://sar.informatik.hu-berlin.de Verteilte Speichersysteme und Anonymität Was bedeutet Anonymität? Der Server weiß nicht, was er bereitstellt. Schwer: Datei mit seperatem Geheimnis verschlüsselt werden. ►Document Anonymity What are u sharing? Serve r

7 7 May 2006 - 7 Systems Architecture http://sar.informatik.hu-berlin.de Was bedeutet Anonymität? Reader What is democracy? Leser möchte ihm durch Pseudonym bekannte Daten herunterladen. Identität des Lesers bleibt geheim. Leser einer Datei können nicht ermittelt werden. ►Reader Anonymity Verteilte Speichersysteme und Anonymität

8 8 May 2006 - 8 Systems Architecture http://sar.informatik.hu-berlin.de Wiederholung 1. Hashwerte: Bsp.: H SHA256 («Democracy») = 2e909f196af2c978bb17e495aa26f8849cad7ff30ce201ab4ba94e722fa80034 H SHA-256 («democracy») = 03fa7265ee6bf42783da1475bde5d79eb49120b6f0d2d956e596159f7fe2dfc2 Beliebige Bitfolge wird Bitfolge konstanter Länge zugeordnet. In der Praxis als Bijektion betrachtet. 2. Asymmetrische Verschlüsselung: Bsp.: Sender: (Democracy) PK mod n = C Sender übermittelt (C) Empfänger: C SK mod n = Democracy Zur Ver- und Entschlüsselung werden verschiedene Schlüssel benutzt. PK – Public Key, SK – Secret Key 3. Signaturen: Bsp.: Sender: (Democracy) SK mod n = Sig Sender übermittelt («Democracy», Sig) Empfänger: Sig PK mod n = Democracy Authenzität einer Nachricht beweisen.

9 9 May 2006 - 9 Systems Architecture http://sar.informatik.hu-berlin.de «We present a design for a system of anonymous storage [..] » «Our design ensures the availability of each document for a publisher-specified lifetime.» Free Haven – Begriffe, Akteure Zielsetzung von Free Haven: Vorhandene Akteure: Autor, Veröffentlicher, Server (servnet node), Leser Idee: Dynamisches Netz von Servern bildet ein Servnet. Server: «Give up space now, get space forever» Dokument wird zerteilt und die «Shares» auf Server des Servnets ausgelagert. Server wissen nicht was sie teilen. (author, publisher, server, reader)

10 10 May 2006 - 10 Systems Architecture http://sar.informatik.hu-berlin.de Servne t Server/servnet node bekannt über ein Pseudonym ordnet anderen SN Reputation und Glaubwürdigkeit zu Autor Kommunikation über speziellen Kommunikationskanal Lese r Free Haven – System: Servnet = Veröffentlicher und servnet node Autor / Veröffentlicher

11 11 May 2006 - 11 Systems Architecture http://sar.informatik.hu-berlin.de Free Haven – Ablauf: Veröffentlichung Democracy is the best kind of government. PK Doc, SK Doc } servnet nodes Alternativ kann dieser Vorgang auch von einem servnet node übernommen werden. Share s documen t Autho r Wie wird das Dokument aufgeteilt? Was passiert wenn ein Share verloren geht oder manipuliert wird?

12 12 May 2006 - 12 Systems Architecture http://sar.informatik.hu-berlin.de Servnet Free Haven – Ablauf: Trading Shares werden durch spezielle Verhandlungen getauscht. Reputationssytem bewertet Zuverlässigkeit von servnet nodes. Servnet Wie werden böse servnet nodes erkannt?

13 13 May 2006 - 13 Systems Architecture http://sar.informatik.hu-berlin.de Free Haven – Ablauf: Retrieval Reade r Atom bomb plan – PK', SK'... Democracy – PK, SK... Why Knut should die – PK'', SK'' Servnet H(PK) Extern von Free Haven:

14 14 May 2006 - 14 Systems Architecture http://sar.informatik.hu-berlin.de Reade r Servnet Kommunikationskanal Anonymität? Democracy is the best kind of government. Free Haven – Ablauf: Retrieval 2

15 15 May 2006 - 15 Systems Architecture http://sar.informatik.hu-berlin.de www.freehaven.de/publisher.html Free Haven Publisher 1 Reply Block: 13AC38091DE... Remailer IP: www.cypherpunk.dewww.cypherpunk.de PK Server1 Free Haven Publisher 2 Reply Block ID: 7816EC0012A... Remailer IP: www.mixmaster.de PK Server2... Kommunikationskanäle Kommunikation zwischen Servern und Benutzern nur indirekt über Kommunikationskanäle. Beispiel: Autor veröffentlicht. = (87.185.158.2,...) PK Remailer = (99.186.15.66,...) PK Remailer2 Democracy is the best kind of government. Destination: www.cypherpunk.de www.cypherpunk.de Reply Block: 13AC38091DE... Data: PK Server Publish: Democracy is the best kind of government.

16 16 May 2006 - 16 Systems Architecture http://sar.informatik.hu-berlin.de Kommunikationskanäle Kommunikation zwischen Servern und Benutzern über Kommunikationskanäle. Beispiel am Autor zum Publishing Server: Cypherpunk Remailer SK Remailer Destination: www.cypherpunk.de www.cypherpunk.de Reply Block: 13AC38091DE... Data: PK Server Publish: Democracy is the best kind of government. Servnet node (Publisher) SK Server Destination: 87.185.158.2 Data: PK Server Democracy is the best kind of government. Kommunikation von Servnet node zum Autor über eigenen Reply Block des Autors.

17 17 May 2006 - 17 Systems Architecture http://sar.informatik.hu-berlin.de System Design Systemstruktur

18 18 May 2006 - 18 Systems Architecture http://sar.informatik.hu-berlin.de System Design Kommunikationsmodul (Comm Modul) Haven Modul Node Datenbank (Node DB) Comm Modul Node DB Haven Mixnet(Interne t) Speicher, Senden von Dateien Trades abarbeiten Server Introduction Pflege des Reputationssystems Buddy Checks Serverkommunikation via Mixnet Indiziert Shares Indiziert Serververtauenswürdigkei t

19 19 May 2006 - 19 Systems Architecture http://sar.informatik.hu-berlin.de Publication Publication(Veröffentlichung)

20 20 May 2006 - 20 Systems Architecture http://sar.informatik.hu-berlin.de Publication Suche von Nodes, welche bereit sind Dokumente zu speichern. Spezielle Nodes mit Veröffentlichungsinterface (zB. Websites oder andere) Reply Blocks von Publiationsservern sind auf Websites veröffentlicht. Anfrage an Servnet Adressen von Publikationsservern

21 21 May 2006 - 21 Systems Architecture http://sar.informatik.hu-berlin.de Publication Kommunikationsverschlüsselung mit PK Server des Publishers. Dateiübertagung zusätzliche Informationen:n - Anzahl der Shares k - Robustheitsfaktor Veröffentlicher emfängt Dateiübertragung über einen anonymen Remailer

22 22 May 2006 - 22 Systems Architecture http://sar.informatik.hu-berlin.de Publication 1. Dateizerlegung durch Information Dispersal Algorithm (IDA) in n Shares (vom Autor vorgegeben) Robustheitsfaktors k k<=n größeres kminimale Share-Größe aber höheres Ausfallrisiko kleineres khöhere Ausfallsicherheit aber große Shares 1. Zerlegen Veröffentlicher

23 23 May 2006 - 23 Systems Architecture http://sar.informatik.hu-berlin.de Publication TODO Veröffentlichung Information Dispersal Algorithm (IDA) 1. Zerlegen vereinfachte Darstellung: k=3 n=6 f1 f2 f3 f4 f5 f6 IDA f1 f3 f4 f5 1 f2 f4 f5 f6 2 f1 f2 f4 f5 3 f3 f4 f5 f6 6... Veröffentlicher

24 24 May 2006 - 24 Systems Architecture http://sar.informatik.hu-berlin.de Publication 2. Schlüsselgenerierung (PK Doc,SK Doc ) Schlüsselpaare zur Signierung und Verschlüsselung der Shares 1. Zerlegen2. Signierung Dokument wird unter dem Hash H(PK Doc ) indiziert. Veröffentlicher

25 25 May 2006 - 25 Systems Architecture http://sar.informatik.hu-berlin.de Publication 3. Datensegmente erzeugen Speichern der Shares auf dem lokalem Serverspeicher 3. Lokal speichern Freigabe der Shares fürs Trading 1. Zerlegen2. Signierung Veröffentlicher

26 26 May 2006 - 26 Systems Architecture http://sar.informatik.hu-berlin.de... cec41f889d75697304e89edbdddf2436662d8c784 1 0 100 60 2007-06-20-15:25:24 Ascii-armored charachters here d75697304e89edbdddf2436662d8c784124ab234... 3. Lokal speichern 1. Zerlegen2. Signierung Publication Veröffentlicher

27 27 May 2006 - 27 Systems Architecture http://sar.informatik.hu-berlin.de Retrieving Retrieving (Suchen/Empfangen)

28 28 May 2006 - 28 Systems Architecture http://sar.informatik.hu-berlin.de Retrieving Dateisuche setzt Kenntnis des Hashwertes H(PK Doc ) voraus. Internet bezieht H(PK Doc ) des Dokuments Reader erfährt PK Doc extern von Free Haven, z.B. über das Eternity Usenet.

29 29 May 2006 - 29 Systems Architecture http://sar.informatik.hu-berlin.de Retrieving Reader sucht Server, welcher Suchanfrage übernimmt und überträgt dann: PK Reader zur sicheren Dateiübertragung Anfrage nach H(PK) von gesuchter Datei seinen eigenen Reply Block Hashwert des PK Doc des zu suchenden Dokuments [H(PK Doc ), PK Reader, reply block(client)]

30 30 May 2006 - 30 Systems Architecture http://sar.informatik.hu-berlin.de Retrieving Server sendet einen Broadcast «in» das Servnet. Anfrage nach H(PK) von gesuchter Datei Broadcast Broadcasts Servnet nodes kennen sich über Pseudonyme und Reply Blocks (servnet nodes kennen sich untereinander nicht ► Server anonymity).

31 31 May 2006 - 31 Systems Architecture http://sar.informatik.hu-berlin.de Retrieving Server empfangen Broadcast: Durchsuchen die lokal gespeicherten Shares. Im Erfolgsfall: Anfrage nach H(PK) von gesuchter Datei BroadcastVerschlüsselt Shares Verschlüsselung des Shares mit PK Reader Senden des Shares und dem Reply Block an den Remailer Sendet Shares

32 32 May 2006 - 32 Systems Architecture http://sar.informatik.hu-berlin.de Retrieving Dateiwiederherstellung nur mit mindestens k Shares Entschlüsselt mit SK Reader Wiederherstellung mittels IDA, SK Doc Dateientschlüsselung mit SK Reader Dateientschlüsselung mit SK Doc Dateiwiederherstellung duch Rekonstruktionsalgorithmus

33 33 May 2006 - 33 Systems Architecture http://sar.informatik.hu-berlin.de Expiration Expiration(Gültigkeit )

34 34 May 2006 - 34 Systems Architecture http://sar.informatik.hu-berlin.de Expiration Shares besitzen Gültigkeitsdatum (absoluter Zeitstempel) Festlegung durch den Autor bei der Veröffentlichung Mit Ende der Gültigkeit erfolgt legales Verwerfen der Shares

35 35 May 2006 - 35 Systems Architecture http://sar.informatik.hu-berlin.de Revocation Revocation (Rückruf)

36 36 May 2006 - 36 Systems Architecture http://sar.informatik.hu-berlin.de Revocation Dateirückruf bei neuer Version oder eventuell geänderten Inhalten Autor/Publisher fügt Shares extra Wert x hinzu. X wird als Hash H(x) codiert Broadcast von x Broadcast von X in das Servnet Alle Shares mit diesem Hashwert werden legal verworfen. Gültigkeit verfällt Server erhalten x und bilden den H(x).

37 37 May 2006 - 37 Systems Architecture http://sar.informatik.hu-berlin.de Buddy Numbering

38 38 May 2006 - 38 Systems Architecture http://sar.informatik.hu-berlin.de Buddy Numbering Ansätz e Verknüpfung von 2 Shares direkt miteinander (buddy 0, buddy 1) Verknüpfung von Share i mit dem des i+1 Share als eine Art Kette Verknüpfung von Share i mit dem i+1 und i+2 ten Share (erhöht Sicherheit und Aufwand) buddy 0 buddy 1 buddy 2

39 39 May 2006 - 39 Systems Architecture http://sar.informatik.hu-berlin.de Accountability and Redundancy (Verantwortlichkeit und Redundanz)

40 40 May 2006 - 40 Systems Architecture http://sar.informatik.hu-berlin.de Accountability Überwachung der Shares duch einen festen Buddy Tauschaktivitäten werden an « Buddy » gemeldet Shareverlust wird per Broadcast anderen Servern mitgeteilt Problem ? Fest eingetragene « Buddys » bieten Angriffs- und Anonymitätslücken Lösun g Implementation des Buddy-Systems als Kette beim Tausch müssen beteiligte Server Benachrichtigung an die Buddys senden

41 41 May 2006 - 41 Systems Architecture http://sar.informatik.hu-berlin.de Redundancy lokale Kopie beim Publisher Partnerteile (Buddys) können den fehlenden Share repoduzieren Mehr Daten zu verwalten, eventuelles expoentielles Wachstum im Fall einer Störung Lösun g Sicherheitsmechanismen Ansätz e Problem ? Robustheitsfaktor k

42 42 May 2006 - 42 Systems Architecture http://sar.informatik.hu-berlin.de Trading Trading(Austausch)

43 43 May 2006 - 43 Systems Architecture http://sar.informatik.hu-berlin.de Trading Vorteil: Erhöht Anonymität durch ständiges Wechseln der Shares über Server. Ermöglicht ein dynamisches Servnet. Bessere Verarbeitung von Dateien mit einem langen Lebenszyklus. Problem: Buddys muss über Wechsel des Server benachrichtigt werden: Verzögerung des Kommunikationskanals Problem: Buddys muss über Wechsel des Server benachrichtigt werden: Verzögerung des Kommunikationskanals

44 44 May 2006 - 44 Systems Architecture http://sar.informatik.hu-berlin.de Receipts Protokollierung von Transaktionen Verlust von Shares kann mittels Receipts nachgewiesen werden. ►Reputation vergesslicher Server kann verringert werden. « I am » :A « I trade to »:B « I gave away »: « I received »: « Timestamp » T Aufba u

45 45 May 2006 - 45 Systems Architecture http://sar.informatik.hu-berlin.de Trading Häufigkeit ist wählbar durch Operator (Admin). Server handelt einen Tausch aus. Tauschkriterien: Dateigröße, Gültigkeit Große Dateien mit langer Gültigkeit gelten als teuer. Trade Anfrag 1. Aushandeln

46 46 May 2006 - 46 Systems Architecture http://sar.informatik.hu-berlin.de Trading Tauschpreisaushandlung Senden einer Receipt Nachricht an die Buddys. Trade Anfrag receipt buddy0buddy1 buddy0 buddy1 2. Handshake

47 47 May 2006 - 47 Systems Architecture http://sar.informatik.hu-berlin.de Trading Trading der Shares und Versenden der Receipts 3. Tauschen/Überprüfung Trade buddy0buddy1 buddy0 receipt Bestätigungen des Trades

48 48 May 2006 - 48 Systems Architecture http://sar.informatik.hu-berlin.de Trading Dateiverlust nach Trade, veranlasst einen Beschwerdebroadcast. Trade buddy0 buddy1 Fehler Beschwerde führt zur Repuationsverringerung des Servers. Broadcast

49 49 May 2006 - 49 Systems Architecture http://sar.informatik.hu-berlin.de Angriffe auf Free Haven Angriffe auf die Anonymität von Benutzern: Bösartige Software kann bei der Benutzung eines Free Haven Clients Benutzer identifizieren. ► IP-Diebstahl Mehrfaches Benutzen von Reply Blocks kann einen Leser (oder Autor) identifizieren. ► Profilerstelllung Angriffe auf die Anonymität von Servern/Veröffentlicher: Einfügen signifikanter Daten, Sammeln von Routing Informationen ► Lokalisierung von Servern

50 50 May 2006 - 50 Systems Architecture http://sar.informatik.hu-berlin.de Angriffe auf Verfügbarkeit von Dokumenten/Reputation von Servern: Eine Menge von Server kann gezielt Shares lagern und diese unbestraft Löschen. Denial of Service auf die Kommunikationskanäle. Wegen der zu garantierenden Anonymität können DOS-Attacken ohne Gegenwehr durchgeführt werden. Einfügen von Unnützen Daten – Data Flooding. Als «guter» Server ausgeben und dann viele Shares Löschen oder andere Server über das Reputationssystem Bestrafen. Angriffe auf Free Haven Mittels eines komplexen Reputationssystem können viele Angriffe eingeschränkt werden. Annahme: Bei genügend großer Anzahl von Servern steigt der Aufwand für die Angreifer überproportional.

51 51 May 2006 - 51 Systems Architecture http://sar.informatik.hu-berlin.de Probleme von Free Haven Broadcast innerhalb des Servnets ist ineffizient. Faires Reputationssystem ist komplex. Bei zu großer Anzahl von Servern sinkt die Performance aller Systeme.

52 52 May 2006 - 52 Systems Architecture http://sar.informatik.hu-berlin.de «The current Free Haven design is unsuitable for wide deployment, because of several remaining problems. The primary is efficiency. An inefficient design will lead to a system with few users. A system with few users will not provide the anonymity we desire.» Zusammenfassung / Diskussion

53 53 May 2006 - 53 Systems Architecture http://sar.informatik.hu-berlin.de 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.  R.R. Dingledine, "Theee 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).  Michael O. Rabin, "Efficient dispersal of information for security, load balancing, and fault tolerance, April 1989.  http://de.wikipedia.org/wiki/Remailer http://de.wikipedia.org/wiki/Remailer  http://de.wikipedia.org/wiki/Freenet http://de.wikipedia.org/wiki/Freenet