Systems Architecture Free Haven Project Gerd Wittchen, Christopher Rudolf

2 May Systems Architecture  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 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture «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 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture Reade r Servnet Kommunikationskanal Anonymität? Democracy is the best kind of government. Free Haven – Ablauf: Retrieval 2

15 May Systems Architecture Free Haven Publisher 1 Reply Block: 13AC38091DE... R er IP: PK Server1 Free Haven Publisher 2 Reply Block ID: 7816EC0012A... R er IP: PK Server2... Kommunikationskanäle Kommunikation zwischen Servern und Benutzern nur indirekt über Kommunikationskanäle. Beispiel: Autor veröffentlicht. = ( ,...) PK R er = ( ,...) PK R er2 Democracy is the best kind of government. Destination: Reply Block: 13AC38091DE... Data: PK Server Publish: Democracy is the best kind of government.

16 May Systems Architecture Kommunikationskanäle Kommunikation zwischen Servern und Benutzern über Kommunikationskanäle. Beispiel am Autor zum Publishing Server: Cypherpunk R er SK R er Destination: Reply Block: 13AC38091DE... Data: PK Server Publish: Democracy is the best kind of government. Servnet node (Publisher) SK Server Destination: Data: PK Server Democracy is the best kind of government. Kommunikation von Servnet node zum Autor über eigenen Reply Block des Autors.

17 May Systems Architecture System Design Systemstruktur

18 May Systems Architecture 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 May Systems Architecture Publication Publication(Veröffentlichung)

20 May Systems Architecture 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 May Systems Architecture 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 R er

22 May Systems Architecture 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 May Systems Architecture 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 f Veröffentlicher

24 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture cec41f889d e89edbdddf d8c :25:24 Ascii-armored charachters here d e89edbdddf d8c784124ab Lokal speichern 1. Zerlegen2. Signierung Publication Veröffentlicher

27 May Systems Architecture Retrieving Retrieving (Suchen/Empfangen)

28 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture 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 R er Sendet Shares

32 May Systems Architecture 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 May Systems Architecture Expiration Expiration(Gültigkeit )

34 May Systems Architecture 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 May Systems Architecture Revocation Revocation (Rückruf)

36 May Systems Architecture 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 May Systems Architecture Buddy Numbering

38 May Systems Architecture 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 May Systems Architecture Accountability and Redundancy (Verantwortlichkeit und Redundanz)

40 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture Trading Trading(Austausch)

43 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture Trading Tauschpreisaushandlung Senden einer Receipt Nachricht an die Buddys. Trade Anfrag receipt buddy0buddy1 buddy0 buddy1 2. Handshake

47 May Systems Architecture Trading Trading der Shares und Versenden der Receipts 3. Tauschen/Überprüfung Trade buddy0buddy1 buddy0 receipt Bestätigungen des Trades

48 May Systems Architecture Trading Dateiverlust nach Trade, veranlasst einen Beschwerdebroadcast. Trade buddy0 buddy1 Fehler Beschwerde führt zur Repuationsverringerung des Servers. Broadcast

49 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture «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 May Systems Architecture 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  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  