The Free Haven Project - Revision history

Crudolf at 20:39, 12 July 2007

2007-07-12T20:39:30Z

← Older revision		Revision as of 20:39, 12 July 2007
Line 74:		Line 74:

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

			TODO

	==== Revocation ====		==== Revocation ====

Crudolf at 20:36, 12 July 2007

2007-07-12T20:36:58Z

← Older revision		Revision as of 20:36, 12 July 2007
Line 69:		Line 69:
	==== Trading ====		==== Trading ====

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

			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.

	==== Revocation ====		==== Revocation ====
Line 83:		Line 87:

	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 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.		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.		Diese gegensätzlichen Ziele führten zum Abbruch des Projekts.

Crudolf at 20:31, 12 July 2007

2007-07-12T20:31:04Z

← Older revision		Revision as of 20:31, 12 July 2007
Line 31:		Line 31:
	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.		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.		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.		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.		Gleichzeitig kann der Remailer die Daten dem Benutzer nicht zuordnen, da sie mit dem öffentlichen Schlüssel des Servers verschlüsselt wurden.

Line 42:		Line 42:
	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.		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:		Grundsätzlich müssen folgende Dinge beim Veröffentlichen geschehen:
	* Die Datei wird mit einem asymmetrischen Schlüsselpaar verschlüsselt, ~~welcher~~ nur der Autor kennt.		* 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.		* 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. Die Gesamtheit dieser Informationen und einem Teil wird als "Share" bezeichnet.		* 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.		* 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.

Line 53:		Line 53:
	==== Retrieval ====		==== Retrieval ====

			Bei einer Anfrage eines Readers werden folgende Dinge gesendet:
	TODO
			* 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.
⚫	==== ~~Expiration~~ ====

			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.
	TODO

	==== ~~Revocation~~ ====		==== Expiration ====

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

	==== Trading ====		==== Trading ====

	TODO		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 ==		== Angriffe ==
Line 71:		Line 80:
	TODO		TODO

	== ~~Probleme~~ ==		== 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.
	TODO
			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 ==		== Quellen ==

Crudolf at 20:15, 12 July 2007

2007-07-12T20:15:34Z

@@ Line 40: / Line 40: @@
 ==== Publication ====
 ==== Retrieval ====
@@ Line 70: / Line 79: @@
 * 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

Crudolf at 20:04, 12 July 2007

2007-07-12T20:04:59Z

← Older revision		Revision as of 20:04, 12 July 2007
Line 65:		Line 65:

	TODO		TODO

			== 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

Crudolf at 14:45, 19 June 2007

2007-06-19T14:45:41Z

← Older revision		Revision as of 14:45, 19 June 2007
Line 55:		Line 55:

	==== Trading ====		==== Trading ====

			TODO

			== Angriffe ==

			TODO

			== Probleme ==

	TODO		TODO

Crudolf at 14:45, 19 June 2007

2007-06-19T14:45:09Z

← Older revision		Revision as of 14:45, 19 June 2007
Line 2:		Line 2:

	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 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 ==		== Akteure, System, Begriffe ==

Crudolf at 14:42, 19 June 2007

2007-06-19T14:42:44Z

@@ Line 26: / Line 26: @@
 {|
 |-
-| [[image:kommunikationskanal.png|thumb|200px|Überblick Servnet]]
+| [[image:kommunikationskanal.png|thumb|200px|Beispiel eines sicheren Kommunikationskanals]]
 |}
@@ Line 35: / Line 35: @@
 Dieser Kommunikationskanal ermöglicht also eine anonyme Kommunikation.

Crudolf at 14:40, 19 June 2007

2007-06-19T14:40:35Z

← Older revision		Revision as of 14:40, 19 June 2007
Line 28:		Line 28:
	\| [[image:kommunikationskanal.png\|thumb\|200px\|Überblick Servnet]]		\| [[image:kommunikationskanal.png\|thumb\|200px\|Überblick Servnet]]
	\|}		\|}

			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.

Crudolf at 14:30, 19 June 2007

2007-06-19T14:30:32Z

← Older revision		Revision as of 14:30, 19 June 2007
Line 6:		Line 6:

	Die Akteure in diesem System sind:		Die Akteure in diesem System sind:
			* Autor - Der Autor will Daten für andere verfügbar machen ohne seine Identität zu veröffentlichen.
	* Autor
			* 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.
	* Veröffentlicher
			* Leser - Der Leser kennt Daten unter einem bestimmten Pseudonym und will diese vom System erhalten.
	* Leser
			* Server - Der Server gibt eigenen Speicher frei und stellt dort Dokumentanteile bereit.
	* Server

	~~Die~~ Akteure Server und Veröffentlicher befinden sich in der Regeln innerhalb des Servnets.		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.

	{\|		{\|
	\|-		\|-
	\| [[image:servnet.png\|thumb\|~~100px~~\|Überblick Servnet]]		\| [[image:servnet.png\|thumb\|200px\|Ü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.

			{\|
			\|-
			\| [[image:kommunikationskanal.png\|thumb\|200px\|Überblick Servnet]]
	\|}		\|}