Author Topic: Die perfekte anonyme Tauschbörse  (Read 11799 times)

0 Members and 1 Guest are viewing this topic.

Offline Eroli

  • Elite
  • *****
  • Posts: 2435
  • Karma: +22/-0
  • StealthNet Developer
    • View Profile
Die perfekte anonyme Tauschbörse
« on: March 14, 2008, 08:46:06 PM »
Hallo zusammen,

da ja immer wieder neue (alte) kritische Stellen an fast jedem Programm laut werden, wollte ich gerne mal fragen, wie das perfekte anonyme P2P aussehen müsste, dass rechtlich so gut wie einwandfrei ist (hummel?) und auch sehr Angreiferresistent. Dazu sollte es natürlich auch noch super Downloadraten haben ;-)

Ich bin gespannt auf eure Konzepte.

Offline Eroli

  • Elite
  • *****
  • Posts: 2435
  • Karma: +22/-0
  • StealthNet Developer
    • View Profile
Re: Die perfekte anonyme Tauschbörse
« Reply #1 on: March 14, 2008, 10:40:34 PM »
Ich versuch mal den Anfang zu machen.

Da das Routing ja mit am wichtigsten ist, dachte ich mir, dass eine richtige "PeerMap" von Vorteil sein könnte. Neben den richtige Kommandos für das Übertragen und Suchen, bräuchte man also eine Art Diagnostikkommandos, mit denen man die besten Routen zu den einzelnen Peers ausfindig macht und diese in der "PeerMap" speichert.

Dann weiß das Programm immer, welche Route am schnellsten zum gesuchten Peer führt.

PRO:
Routen sind für Downloads bereits ausgekundtschaftet

KONTRA:
Zusätzlicher Traffic
PeerMap wird bei vielen Benutzern riesig


Was meint ihr?


Offline Nemo

  • Global Moderator
  • Elite
  • *****
  • Posts: 1303
  • Karma: +27/-0
    • View Profile
Re: Die perfekte anonyme Tauschbörse
« Reply #2 on: March 15, 2008, 07:23:07 PM »
Da das Routing ja mit am wichtigsten ist, dachte ich mir, dass eine richtige "PeerMap" von Vorteil sein könnte. Neben den richtige Kommandos für das Übertragen und Suchen, bräuchte man also eine Art Diagnostikkommandos, mit denen man die besten Routen zu den einzelnen Peers ausfindig macht und diese in der "PeerMap" speichert.

Dann weiß das Programm immer, welche Route am schnellsten zum gesuchten Peer führt.
Soweit ich weiss, sammeln alle Ants-basierten Routingprotokolle Angaben darüber, über welchen direkten Nachbarn die anderen Peers erreicht werden können. Welche Änderungen schlägst du nun vor?

Routingprotokolle existieren sicherlich hunderte, davon sind vermutlich nur wenige in grösserem Einsatz. Bei anonymen P2P-Netzwerken wäre die direkte Datenübertragung die schnellste Art, dies würde jedoch die Anonymität gefährden.
Anonyme P2P-Netzwerke mit einer zufälligen Wahl der direkten Nachbarn erinnern mich an mein anderes Interessengebiet, den Ad-Hoc-Netzen aufgebaut mit WLAN-Routern. Für diese spontanen und chaotischen Funknetzwerke werden spezielle dynamische Routingprotokolle erfunden, wobei die meisten nur theoretisch existieren und nur die wenigsten praxistauglich sind. Bei vermaschten Funknetzwerken gibt es Links, die nur in die eine Richtung funktionieren; Links mit schwankenden Signalqualitäten und grossen Paketverlusten, ausserdem kann immer wieder ein neuer Router dazukommen oder wegfallen. Bei Freifunk wird in der aktuellen Firmware OLSR eingesetzt, das B.A.T.M.A.N.-Protokoll ist noch als experimentell zu betrachten. Dieses "B.A.T.M.A.N."-Protokoll funktioniert vergleichbar zu den Ants-basierten anonymen P2P-Netzwerken (nur der nächste Nachbar wird fürs Routing betrachtet, bei OLSR wird in jedem Router die gesamte Netztopologie nach den verlustärmsten Wegen durchsucht).

Just my 2 cents.

MfG,
Nemo.

Offline hummel

  • Elite
  • *****
  • Posts: 429
  • Karma: +12/-0
    • View Profile
Re: Die perfekte anonyme Tauschbörse
« Reply #3 on: March 31, 2008, 08:36:42 PM »
Eigentlich habe ich mich mir schon des öfteren Gedanken gemacht, wie sich "perfekte" anonyme Kommunikation (oder in unserem Fall: Filesharing) realisieren liesse. Eine meiner Ideen packt das folgende Problem an:

Das Prinzip der meisten bestehenden aP2P-Technologien liegt darin, dass ein übermitteltes Datenpäcken nur wenig Aufschluss gibt über:
1) seinen ursprünglichen Absender oder Inserter sowie den wahren Adressaten (wie bei MUTE, StealthNet, GNUnet, Freenet), oder
2) seinen logischen Inhalt: via Multi-Use Encoding (wie bei OFF) oder End-to-End Verschlüsselung (bei I2P in Verbindung zusammen mit 1) ).

Leider ist es so, dass ein einzelnes Datenpäckchen zwar nur wenig, aber immerhin etwas Information über die Kommunikationspartner (resp. seinen logischen Inhalt bei OFF) verrät. Erhält ein Knoten in Freenet oder StealthNet eine Anfrage nach einem bestimmten Datenpaket oder wird ein solches durch den Knoten durchgeleitet, kann man daraus gewisse Schlüsse ziehen: Da die Routen in einem aP2P-Netz nämlich nicht beliebig lang sind, besteht eine erhöhte Wahrscheinlichkeit, dass man als Zwischenglied mit dem wahren Absender (oder dem Adressaten des Päckchens) direkt verbunden ist. Es ist also wahrscheinlicher, dass eines der direkten Nachbarknoten der tatsächliche Tauschpartner auf dieser Route ist als ein beliebiger anderer Knoten, der gerade online ist.

In OFF ist es ähnlich: Ein Block kann nur für eine begrenzte Zahl von Dateien verwendet werden (im Schnitt 3). Es ist aber denkbar, dass ein bestehender Block auch in Dateien, deren URL nicht veröffentlicht wird, Verwendung findet.

Zwar verrät ein durchgeleiteter Block nur wenig über die eigentlichen Tauschpartner. Jedoch lässt sich durch wiederholte Messung relativ viel herausfinden. Dies deshalb, weil ein Knoten nicht einfach irgendwelche zufälligen Datenblöcke anfordert, sondern solche, die miteinander zusammenhängen. Vor allem lassen sich die Blöcke einzelner Dateien korrelieren, wenn deren Aufteilung bekannt ist. Weil auch der Client eines normalen Benutzers irgendwie herausfinden muss, welche Blöcke für die angefragte Datei benötigt werden, hat auch ein allfälliger Angreifer diese Möglichkeit.
Hat der Feind überdies genügend Knoten zur Verfügung, kann er diese (mehr oder weniger) gezielt einsetzen, um seine Nachbarknoten damit auszuspionieren. Im schlimmsten Fall (bei genügend vielen Einzelbeobachtungen) kann er mit einer hohen Wahrscheinlichkeit feststellen, was ein beobachteter Knoten gerade lädt oder anbietet.

Natürlich ist dies nicht immer ganz einfach, weil auch andere Faktoren eine Rolle spielen. Bei Ants-Routing-Netzen wie StealthNet werden die Routen nämlich nicht von irgendwelchen (zufälligen) Hashwerten und Node IDs bestimmt, sondern sie stellen sich in einem Selbstoptimierungsverfahren quasi von selbst ein. Allerdings lassen die Datenpakete auch hier gewisse Rückschlüsse auf die Tauschpartner zu, vor allem wenn man zu diesem Zweck im Rahmen einer aktiven Attacke die Routen gezielt manipuliert.

Letzten Endes hängt der Erfolg von den eingesetzten Ressourcen ab.

Gegen diese Attacken wird als Abhilfe zumeist vorgeschlagen, dafür zu sorgen (z.B. durch längere und zufälligere Routen oder durch verschiedene Arten oder Schichten von Verschlüsselungen), dass einzelnen Anfrage so wenig Infos wie möglich bereithalten. Leider führen solche Vorschläge in der Regel aber zu erheblichen Performance-Einbussen.

Eine meines Erachtens viel naheliegendere Lösung wird hingegen praktisch nirgends diskutiert: Wie kann man erreichen, dass sich die „altruistischen“ Aktivitäten eines Knotens nicht von seinem „egoistischen“ Verhalten unterscheiden lassen?
Verhält sich nämlich jeder Knoten im Netz unabhängig von den von seinem Benutzer ausgeführten Anweisungen genau gleich wie jeder andere, sind Korrelationsattacken unschädlich. Mit anderen Worten dürfte sich ein Knoten, der benutzer- und führerlos ausschliesslich altruistischen Aktivitäten nachgeht, nicht von einem manuell gesteuerten unterscheiden.

Wäre dies möglich, so könnte man getrost auf die Verschleierung der einzelnen Anfragen/Datenblöcke und den dadurch verursachten Overhead verzichten.

Ich behaupte nun, dass diese Idee grundsätzlich realisierbar ist und sich ein vom Benutzer selbst ausgewählter Grad an Anonymität praktisch garantieren lässt. D.h. Abstreitbarkeit kann nicht mit Attacken des Gegners zu Nichte gemacht werden.
Allerdings ist meine Idee nur dann durchführbar, wenn die Datenblöcke bei den Knoten zwischengespeichert werden und man juristisch und moralisch alles auf die Karte der plausible deniability setzt. Aber für einmal konzentriere ich mich auf die technische Machbarkeit und kümmere mich nicht um das Rechtliche.
Mein Vorschlag eignet sich sowieso nur für „Hartgesottene“ Ausserdem benötigt mein Konzept gewisse heuristische Methoden, die eventuell eine mathematische Herausforderung sein können. (Anonymität hat leider seinen Preis!)

Ich bin mir nicht sicher, wie ich meinen Vorschlag einigermassen verständlich erklären soll. Er ist nämlich zugegebenermassen ein bisschen verrückt. Aber ich versuchs trotzdem:

Das Netz ist komplett offen (opennet): Es ist für jedermann ersichtlich, welcher Knoten wann online ist. Ausserdem findet die Kommunikation zwischen den Knoten unverschlüsselt statt. Jeder Knoten weiss, dass die von einem anderen Knoten angeforderten Blöcke für diesen selbst bestimmt sind und nicht weitergeleitet werden!
Ob die Blöcke mit einem Schlüssel, der ebenfalls im Netz erhältlich ist und separat angefordert werden kann, verschlüsselt sind, kann dahin gestellt bleiben. Im Sinne der plausible deniability wäre streng genommen nicht einmal dies erforderlich, weil zumindest ein gewöhnlicher Computerbenutzer mit den gecacheten 32kb Blöcken einer Datei nicht viel anfangen kann. Selbst wenn sämtliche Blöcke vorhanden sind, wird er sie kaum in der richtigen Reihenfolge zu einer funktionsfähigen Datei zusammensetzen können.
Das einzige was dem Benutzer verborgen bleiben muss, sind die von seinem Knoten altruistisch durchgeführten Aktivitäten.

Neben dem eigentlichen Netz, in dem die Transfers wie gesagt unverdeckt stattfinden, braucht es ein Hilfsnetz, welches auf hohe Anonymität ausgelegt ist, wo aber die Performance eine sehr untergeordnete Rolle spielt. Das sich autonom organisierende, pyramidenförmige aufgebaute DC-Netz-Verfahren, das Capi und vor einigen Monate erarbeitet haben, würde sich dafür eignen.
Zweck dieses Hilfsnetzes ist es, eine Art Statistik über die wahren Aktivitäten der Benutzer zu erstellen, die es bei Bedarf ermöglicht, ein völlig authentisches, aber zufällig generiertes Benutzerprofil zu erstellen.

Dafür wird in regelmässigen Zeitabständen ein Verfahren ausgelöst, das folgende Schritte beinhaltet:
1) Jeder Knoten führt ein eigenes (geheimes) Protokoll über die vom Benutzer heruntergeladenen Dateien. Aus Sicherheitsgründen werden die Downloads dort erst aufgeführt, sobald sie komplett abgeschlossen sind. (Fakultativ kann die Liste ausserdem mit ein wenig Salt angereichert werden.) Was zu geschehen hat, wenn der Benutzer neu ist und noch keine (oder nicht genügend) Dateien selber heruntergeladen hat, muss noch diskutiert werden.

2) Nun wählt der Client aus dieser Liste eine zufällige Anzahl von Dateien zufällig aus. Dabei sollte der Zufallsgenerator sehr alte Downloads mit einer geringeren Häufigkeit auswählen als neuere, damit sich schliesslich das gesamte Netz der aktuellen Entwicklung anpassen kann. Die ausgewählten Dateien (resp. ihre Hashwerte) werden mit dem öffentlichen Schlüssels eines des in der Pyramidenhierarchie zuoberst stehenden Knotens verschlüsselt und mit einem Pseudonym versehen, das keinen Aufschluss über die Identität des Knotens gibt und schliesslich abgesendet. (Zu den Details siehe...)

3) Sobald sämtliche Dateilisten bei den obersten Knoten angekommen sind, werden sie entschlüsselt, zusammengefasst und sämtlichen Clients im Netz zur Verfügung gestellt.

4) Jeder Client speichert nach jedem Austauschzyklus die so erhaltenen Liste bei sich ab und überführt sie in eine Datenbank. Aus Datensätzen wie X lud a, b, c, Y lud b, d, e herunter wird eine Wahrscheinlichkeitstabelle (Tabelle 1) erstellt: wer a lädt, wird mit 5% Wahrscheinlichkeit b, mit 2% Wahrscheinlichkeit e laden, usw. Diese Wahrscheinlichkeiten, die zwischen je zwei Dateien festgelegt werden, und mit jedem Zyklus umfangreicher und genauer werden, nenne ich im Folgenden Distanz zwischen zwei Dateien.
Daneben wird eine zweite Tabelle erstellt, die einfach die absoluten Download-Häufigkeiten der einzelnen Dateien enthält (Tabelle 2).

Wieder auf das Hauptnetz bezogen, müssen sich die Knoten beim ersten Programmstart eine eindeutige Identifikation geben. (Diese Identifikation kann sich aber im Laufe der Zeit verändern). Dafür wählen sie gemäss Tabelle 2 mit einem gewichteten Zufallsgenerator eine gewisse Datei als Node ID aus. Diese ID wird im Netz auf Anfrage von anderen Knoten bekannt gegeben. Sollte das Netz irgendwann eine Grösse von mehreren 1000 Knoten umfassen, kann man für anhand der Node IDs und der dazwischenliegenden Distanzen gemäss Tabelle 1 eine der XOR-Metrik (Kademlia) entsprechende DHT aufbauen. Dabei gilt als Besonderheit, dass die einzelnen Nodes die zwischen ihnen liegenden Distanzen nicht exakt gleich beurteilen, weil ihre Distanztabellen unterschiedlich genau sind. Aber das sollte, denke ich, kein grösseres Hinderhins darstellen.

Nun wählt der Knoten n Dateien mit einer möglichst geringen Distanz zu seiner eigenen ID aus. Die für diese Dateien benötigten Blöcke wird der Knoten nun künftig altruistisch herunterladen und im Cache abspeichern. Daneben werden natürlich in einem vom Benutzer festzulegenden Verhältnis die Blöcke für die manuell angeforderten Dateien heruntergeladen und ebenfalls im Cache abgelegt. Sobald die altruistisch angefragten Dateien komplett (oder grösstenteils) heruntergeladen wurden, werden neue ausgewählt. Dieses Mal wird auch die Distanz zu den vom Benutzer herunterzuladenden Dateien bei der Auswahl berücksichtigt.

Unterschreitet die durchschnittliche Distanz der Node ID zu den altruistischen und egoistischen Downloads einen gewissen Schwellenwert, wird der Hash einer neuen Datei als ID gewählt, falls diese günstiger liegt.

Das Auffinden der Blöcke der aktuellen Downloads erfolgt dann auf folgende Art:

Der Knoten sucht sich unter seinen direkten Nachbarn denjenigen heraus, dessen ID die kürzeste Distanz zu einer der angefragten Dateien aufweist. Auf dessen Anfrage liefert der Nachbar zunächst von allen Knoten, die er kennt, diejenigen zurück, die noch näher an der Datei sind als er. Von den angefragten Blöcken schickt er diejenigen, die er selber besitzt, (eventuell nach einem künstlichen Delay) dem Anfrager gleich selber. Bezüglich der restlichen Blöcke, entscheidet er aufgrund eines Ökonomie- oder Karma-Systems (dessen Ziel es ist, den eigenen Karma-Wert zu maximieren, resp. mit den Blöcken „fiktiv“ Geld zu verdienen, um dieses für die Beschleunigung der eigenen Downloads wieder auszugeben), ob er diese selber besorgt und danach weiterleitet oder es sein lässt. Als Option (aus rechtlichen Gründen vor allem) könnte man noch einbauen, dass solche weitergeleiteten Blöcke nicht (oder nur mit einer bestimmten Wahrscheinlichkeit) im Cache des Zwischenknotens gespeichert werden sollen.

Somit sind bei einer Anfrage nach einem Block drei Möglichkeiten denkbar:
1)   Der Knoten lädt den Block für den Benutzer herunter.
2)   Der Knoten lädt den Block im Rahmen eines altruistischen Downloads für den eigenen Cache herunter.
3)   Der Knoten lädt den Block in den Arbeitsspeicher, um ihn später einem anderen weiterzuleiten.

Das Merkwürdige am ganzen System ist, dass die Anonymität des Benutzers nicht davon abhängt, wie er das Verhältnis altruistische/manuelle Downloads bei sich einstellt.
Die Wahrscheinlichkeitstabelle (Tabelle 1) sollte nämlich gewährleisten, dass ein Set von ausschliesslich altruistischen Anfragen eben nicht zufällig ist, sondern genau gleich „aussieht“ wie eine egoistische Anfrage.
Weil der Angreifer nicht weiss, wie das erwähnte Verhältnis eingestellt ist, sind für ihn alle Knoten gleich. Demzufolge könnte er nur gestützt auf einen sämtliche Knoten miteinbeziehenden Durchschnittswert behaupten, die von einem Knoten angefragte Datei würde mit einer gewissen Wahrscheinlichkeit vom Benutzer selbst angefragt werden.

Obschon sich mit diesem System ein bestimmter Grad an Anonymität gewährleisten lässt, indem es gegen bekannte Attacken immun ist, bleibt am Ende leider ein ungutes Gefühl zurück.

Salopp ausgedrückt kann man sich z.B. fragen: Was ist besser, 50% garantierte Abstreitbarkeit für alle Knoten, oder eine Angriffsmöglichkeit, die nur in 50% der Fälle erfolgreich ist, den User dafür aber mit an Sicherheit grenzender Wahrscheinlichkeit enttarnt!

Was bedeutet Anonymität eigentlich für euch?
« Last Edit: June 21, 2008, 01:09:44 PM by hummel »

Offline teotester

  • Regular
  • **
  • Posts: 51
  • Karma: +0/-0
    • View Profile
Re: Die perfekte anonyme Tauschbörse
« Reply #4 on: April 01, 2008, 08:44:23 PM »
Von der theoretischen Strukturierung ; Anonymisierung , Routing/Effizienz und mögliche Angriffsmöglichkeiten Abwehren stehen Freenet und Gnunet bei mir ganz oben.   

In den praktischen Teil müssen all die Elemente auch codiert werden und dann von Rechner abgearbeitet werden, Änderungen müssen von den Entwicklern abgestimmt werden: Alles arbeitsintensiv und langwierig.

Ein kleines Programm mit einfachen Routingprotokoll kann schneller entwickelt werden, und läuft bis zu einer gewissen Benutzeranzahl schneller.  Wenn die Verwaltung der clients überhand nimmt, oder einige Clients bewusst oder unbewusst falsche Steuersignale/Anfragen ins Netzwerk senden, werden die Vorteile des einfachen und schnellen Routingprotokollen hinfällig.

zu Hummels Beitrag:
Auch wenn Zwischenspeicherung auf den Knoten umstritten ist, es gibt einige Vorteile bei der Nutzung. Beide Netzwerke, Freenet und Gnunet haben Zwischenspeicherung implementiert.


my 2 cents





 

Offline philharmoni

  • Elite
  • *****
  • Posts: 878
  • Karma: +10/-0
    • View Profile
Re: Die perfekte anonyme Tauschbörse
« Reply #5 on: April 01, 2008, 10:45:49 PM »
@Hummel: Super Beitrag, auch wenn ich nicht immer folgen konnte. ;D

Ich persönlich halte ehrlich gesagt keine der bisher existierenden Lösungen für ausreichend - im Hinblick auf den Schutz vor der Justiz. Und da wären wir auch bei der Frage nach der Anonymität. Programme wie StealthNet oder auch I2P sind ja wirklich dazu in der Lage, den Schlüsselfiguren eines Dateitauschs (den Up- und Downloadern) einen relativ hohen Grad an Anonymität zu gewährleisten.

Worauf es aber hauptsächlich ankommt - und da würden mir sicher die meisten Filesharer zustimmen - ist, für sein Handeln (sollte es illegal sein) nicht belangt werden zu können. Und da stoßen die bisher existierenden Lösungen an ihre Grenzen. Sie schaffen zwar Anonymität, aber keinen ultimativen Schutz vor der Justiz. Die Teilnehmer der Netzwerke können für ihr Handeln problemlos belangt werden und sei es nur für das Durchleiten von Datenpaketen. Außerdem könnten die Netzwerke irgendwann auch einfach verboten werden - in dem Sinne, dass das Durchleiten von Datenpaketen urheberrechtlich geschützten Materials bestraft wird. Das würde einem Verbot fast gleich kommen.

Die Ultimative Lösung würde für mich daher so aussehen, dass niemand auch nur erfährt, dass ich an Netzwerk XY teilnehme. Dies läuft zwangsläufig auf ein F2F-Netzwerk hinaus. Auch da bleibt meine Teilnahme (bzw. das Wissen darüber) zwar nicht anonym, aber eben unter Freunden. Erweitert um Schnittstellen zu anderen Netzwerken (Turtle-Hopping) ließe sich sogar ein zumindest teiloffenes Gesamtnetzwerk erreichen mit entsprechend großem Angebot. Generell bin ich aber weiterhin für alle Designs anonymer Netzwerke offen. Ich finds schön, dass es diese Diskussion hier gibt. :)
« Last Edit: April 02, 2008, 08:40:54 AM by philharmoni »

Offline echelon

  • Elite
  • *****
  • Posts: 327
  • Karma: +8/-0
    • View Profile
Re: Die perfekte anonyme Tauschbörse
« Reply #6 on: April 02, 2008, 10:55:50 AM »
Hi!

Nur als Anmerkung: F2F (friend to friend) kann nicht funktionieren, da du per se KEINEN Freund hast, dem du deinen gesamten Traffic anvertrauen kannst!
Und angenommen, du kennst jemanden, dem du zu 100% vertraust, wie stellst du sicher, daß dieser/diese nicht alles mitprotokolliert und das meistbietend verkauft, an die Polizei weiterreicht,...?

WebOfTrust gut und schön, aber mein Leben will ich davon nicht abhängig machen.

echelon

Offline hummel

  • Elite
  • *****
  • Posts: 429
  • Karma: +12/-0
    • View Profile
Re: Die perfekte anonyme Tauschbörse
« Reply #7 on: April 02, 2008, 12:35:28 PM »
Nur als Anmerkung: F2F (friend to friend) kann nicht funktionieren, da du per se KEINEN Freund hast, dem du deinen gesamten Traffic anvertrauen kannst!
Das sehe ich leider auch so. Aber anscheinend gibt es viele Leute (inkl. Entwickler), die sich explizit diesem Konzept verschrieben haben. Das Problem ist vor allem, dass man zumeist sowieso nur "online"-Freunde haben wird. Noch grotesker wird es, wenn man sich die Freunde automatisch per ref-bot beschafft, so wie das bei Freenet-Darknet der Fall war/ist.

Und angenommen, du kennst jemanden, dem du zu 100% vertraust, wie stellst du sicher, daß dieser/diese nicht alles mitprotokolliert und das meistbietend verkauft, an die Polizei weiterreicht,...?
Denkst Du da an die Vorfällle in Liechtenstein?

Offline Nochbaer

  • Advanced
  • ***
  • Posts: 258
  • Karma: +8/-0
    • View Profile
Re: Die perfekte anonyme Tauschbörse
« Reply #8 on: April 02, 2008, 03:16:11 PM »
F2F ist schön und gut,solange man im privaten/persönlichen Bekanntenkreis bleibt.

Aber da man nur im privaten Kreis bleiben würde, würde sich die Anzahl der zur Verfügung stehenden Dateien nicht erhöhen, wenn nicht mindestens einer noch eine andere Quelle als das F2F-Netzwerk hat. Da diese andere Quelle nicht (genauso) sicher ist, macht sie diesen F unsicher. Dieser gefährdet dadurch das ganze Netzwerk. Fazit: Man kann auch gleich selbst auf diese andere Quelle zugreifen.

Offline Nemo

  • Global Moderator
  • Elite
  • *****
  • Posts: 1303
  • Karma: +27/-0
    • View Profile
Re: Die perfekte anonyme Tauschbörse
« Reply #9 on: April 02, 2008, 08:01:09 PM »
Nur als Anmerkung: F2F (friend to friend) kann nicht funktionieren, da du per se KEINEN Freund hast, dem du deinen gesamten Traffic anvertrauen kannst!
Und angenommen, du kennst jemanden, dem du zu 100% vertraust, wie stellst du sicher, daß dieser/diese nicht alles mitprotokolliert und das meistbietend verkauft, an die Polizei weiterreicht,...?
Die gleiche Aussage macht auch ein Kommentar zum Slashdot-Artikel über den frisch veröffentlichten Freenet 0.7 Release Candidate 1:

Quote
Re:Pedophiles (Score:5, Interesting)
------------------
by paganizer (566360) <thegrove1NO@SPAMhotmail.com> on Monday March 31, @05:58PM (#22925396)

it's a darknet.
The big draw of the Darknet system, to the best of my knowledge, is that it makes you less likely to be noticed in the first place, and you can sort of "pick & choose" which nodes your computer talks to.
Lets put this in a real world situation:
You are A tibetan, living in the U.S.; you have a Darknet made up of other Tibetans, some of them living in China, some in Tibet. You use Freenet 0.7 to plan protests.
If one of your darknet members gets caught by the chinese government, for whatever reason, they will take that persons computer and analyze it. assuming the person did not put the Freenet 0.7 files in a encrypted volume, they then have the IP address of each computer that persons Freenet 0.7 node talked to; since it's a Darknet, they know that those computers are probably involved with the same thing the person they caught was involved in.
In a Open Net (Freenet 0.5), no matter how they analyze the persons computer, they can't say anything about the other nodes the examined computer talked to except that they are running Freenet 0.5; they are still most likely screwed if they live in China or Tibet, but they could conceivably be a little less screwed.

There are some other security improvements in 0.7; nothing is stopping the Freenet developers from putting those improvements on the 0.5 system.

In meinen Augen würde eine Mischversion zwischen F2F und Public P2P Sinn machen: Leute, die einander vertrauen, bauen Links zueinander auf. Die Daten werden auch zu Freunden von Freunden durchs ganze Netzwerk geroutet (Turtle-Hopping oder so ähnlich wird das genannt).
Da jeder Teilnehmer nur eine handvoll Verbindungen ins Netz hat, wird das Risiko gemäss den Entwicklern minimiert und so könnte die Polizei immer nur einen kleinen Teil des Netzes hochnehmen. Das Netz funktioniert trotzdem weiter, ähnlich den gefürchteten Terrorzellen (Sorry für den unpassenden Vergleich, ist mir so eingefallen).

Bei öffentlichen anonymen P2P-Netzwerken geht man klar in der Masse unter, dafür ist das Netzwerk an und für sich auffälliger: Mittels Seednodes, Webcaches, IRC-Kanäle, Multicast-Adressen oder was auch immer finden die Peers zu anderen wildfremden Peers. Da ist es nicht sehr schwierig, eine Liste mit allen (oder zumindest vielen) Peers zu sammeln (Node Harvesting).

Bei Freenet0.7 gibt es ja den Darknet- und den Opennet-Modus. Jeder kann selber entscheiden, ob er nur bei einem Darknet mitmachen will oder ob er noch gleichzeitig im Opennet tätig ist. So wie ich es verstanden habe, ist das Opennet einerseits ein einfacher Einstieg in das Netzwerk (in der Theorie sollte man so vertrauenswürdige Peers für den reinen Darknet-Modus finden... ::)), andererseits ist das Opennet das Transitnetz von und zu allfälligen angeschlossenen Darknets. Es wird sich sicherlich noch zeigen, wie gut sich dies bewährt...

Just my 2 cents für weitere Diskussionen.

MfG,
Nemo.

Offline philharmoni

  • Elite
  • *****
  • Posts: 878
  • Karma: +10/-0
    • View Profile
Re: Die perfekte anonyme Tauschbörse
« Reply #10 on: April 03, 2008, 06:46:51 AM »
Nur als Anmerkung: F2F (friend to friend) kann nicht funktionieren, da du per se KEINEN Freund hast, dem du deinen gesamten Traffic anvertrauen kannst!
Naja, das kommt doch wohl einerseits auf deine Freunde und andererseits auf deinen Traffic - sprich, was du hoch und runterlädst - an.  :)

Das Problem ist vor allem, dass man zumeist sowieso nur "online"-Freunde haben wird. Noch grotesker wird es, wenn man sich die Freunde automatisch per ref-bot beschafft, so wie das bei Freenet-Darknet der Fall war/ist.
Klar ist, dass man bei F2F-Netzwerken natürlich immer aufpassen muss, wen man als "Freund" bezeichnet. Aber man ist dabei eben selbst seines eigenen Glückes Schmied. Jeder trägt selbst die Verantwortung über das Ausmaß seiner Sicherheit. Wer ganz sicher sein will, verbindet sich eben nur zu den fünf Leuten, die er schon seit x Jahren persönlich kennt. Wer zu Abstufungen bei der Sicherheit bereit ist, verbindet sich eben auch mit Leuten, die er z.B. aus einem Board kennt.

F2F ist schön und gut,solange man im privaten/persönlichen Bekanntenkreis bleibt.

Aber da man nur im privaten Kreis bleiben würde, würde sich die Anzahl der zur Verfügung stehenden Dateien nicht erhöhen, wenn nicht mindestens einer noch eine andere Quelle als das F2F-Netzwerk hat. Da diese andere Quelle nicht (genauso) sicher ist, macht sie diesen F unsicher. Dieser gefährdet dadurch das ganze Netzwerk. Fazit: Man kann auch gleich selbst auf diese andere Quelle zugreifen.
Bei reinen F2F-Netzwerken hast du immer ein sehr begrenztes Dateiangebot, das ist selbstverständlich und liegt in der Natur der Sache. Dafür hat man ein Maximum an Sicherheit - wenn man bei der Auswahl seiner "Freunde" aufpasst. Bei teiloffenen F2F-Netzwerken (Turtle-Hopping) hast du die Einschränkungen beim Angebot hingegen nicht in dem Maße. Dennoch ist dieses Netzwerkdesign (praktische Umsetzungen gibt es bisher kaum) äußerst sicher.

In meinen Augen würde eine Mischversion zwischen F2F und Public P2P Sinn machen: Leute, die einander vertrauen, bauen Links zueinander auf. Die Daten werden auch zu Freunden von Freunden durchs ganze Netzwerk geroutet (Turtle-Hopping oder so ähnlich wird das genannt).
Da jeder Teilnehmer nur eine handvoll Verbindungen ins Netz hat, wird das Risiko gemäss den Entwicklern minimiert und so könnte die Polizei immer nur einen kleinen Teil des Netzes hochnehmen. Das Netz funktioniert trotzdem weiter, ähnlich den gefürchteten Terrorzellen (Sorry für den unpassenden Vergleich, ist mir so eingefallen).
Das ist genau das was ich auch meinte.

Teiloffene F2F-Netzwerke sind für einen selbst immer so sicher, wie man es gerne hätte. Du kannst dein Risiko absolut minimieren um den Preis eines kleinen Dateiangebotes. Oder du gehst mehr Risiko ein, hast aber auch Zugriff auf deutlich mehr Dateien. Aus marktwirtschaftlicher Sicht (Spieltheorie) ist das so absolut logisch und sinnvoll. Wer viel riskiert, kann auch viel gewinnen, aber auch viel verlieren.

Offline hummel

  • Elite
  • *****
  • Posts: 429
  • Karma: +12/-0
    • View Profile
Re: Die perfekte anonyme Tauschbörse
« Reply #11 on: April 25, 2008, 09:06:33 PM »
Schon im vergangenen Jahr habe ich mich mit verschiedenen Ideen herumgeschlagen: Wie kann man effizientes und (wirklich) anonymes Filesharing zugleich realisieren? Die bestehenden Konzepte verwirklichen die Anonymität bekanntlich meistens zulasten der Effizienz.

Eines meiner angedachten Konzepte erschien mir lange Zeit als besonders vielversprechend, obschon ich damit nie wirklich weit gekommen bin. In den letzten Tagen aber, nachdem mein Prüfungsstress endlich vorbei war, konnte ich mich wieder einige Stunden intensiv damit auseinandersetzten. Nach etlichen Skizzen, einigen Berechnungen und Simulationen bin ich demnächst soweit, dass ich es in einem Entwurf niederschreiben kann.
Dies werde ich allerdings nur dann tun, wenn von eurer Seite aus wirkliches Interesse besteht. Denn meine Ideen sind, zumindest was die Details angeht, nicht immer ganz einfach zu verstehen. Wenn ich aber viel Zeit in eine möglichst klare Ausarbeitung investiere, und der Leser sich auch die Zeit zum Durchlesen nimmt, sollte wohl das meiste - so hoffe ich zumindest - verständlich sein. Also bitte seid ehrlich!
Denn ich werde bestimmt einige Wochen brauchen, um einen ersten Entwurf zu Papier zu bringen. Und ich möchte all das nicht vergebens tun. Am besten wäre es, wenn wir das System später gemeinsam verbessern und weiterentwickeln könnten. Denn praxistauglich wird mein erster Entwurf in dieser Form noch kaum sein. Und was gewisse technischen Dinge betrifft, fehlt mir leider auch das nötige Detailwissen.
Bezüglich Ausfallsicherheit des Systems bei DoS-Attacken bin ich momentan ratlos.


Ich werde die wichtigsten Punkte des Konzepts aufzeigen, damit Ihr euch ein erstes Bild machen könnt.

Ziele meines Konzepts mit dem Kodenamen CMIYC (= Catch me if you can!)
- Hohe bis sehr hohe Anonymität, die sich eventuell auch konfigurieren lässt
- Hohe Downloadgeschwindigkeiten durch direkten Download der Datenblöcke (ohne irgendwelches Routing)
- Akteptable Insertgeschwindigkeit durch direkte Uploads, wobei jedoch eine nicht unerhebliche Anzahl von zusätzlichen Korrekturblocken verschickt werden muss, um für Redudanz und Ausfallsicherheit zu sorgen.
- Der Download eines Blocks sollte innerhalb des Netzwerks nicht mehr als 100% Overhead bezüglich der Blockgrösse sowie einen davon unabhängigen konstanten Overhead (Verwaltungsaufwand) verursachen. Dieser konstante Overhead (Verwaltungsaufwand) wird allerdings recht hoch sein.
- Das anfängliche Inserten eines Blocks sollte innerhalb des Netzwerks (also nicht direkt beim Uploader) zusammen nicht mehr als ein paar Hundert Prozent Overhead generieren.

Funktionsweise (Download von Datenblöcken)
- Die Dateien werden wie bei Freenet oder OFF in Blöcke zerteilt und beim Inserten auf verschiedene Knoten im Netz verteilt.

- Eine Besonderheit resp. ein Problem ist, dass die Blöcke aus bestimmten Gründen sehr gross sein müssen. Intuitiv geschätzt wohl mehrere MBytes. Anderenfalls könnte die Funktionalität des Netzwerks aus technischen Gründen kaum gewährleistet werden.

- Downloads erfolgen immer direkt, d.h. ohne irgendwelches Routing

- Allerdings wird ein Block durch den Download gewissermassen "verbraucht" und vom sendenden Knoten daraufhin gelöscht.

- Dies bedingt, dass ein Block vor dem eigentlichen Download auf einem anderen Knoten dupliziert werden muss.

- Durch diese Duplikation erhält ein Block eine neue Verschlüsselung.

- Damit ein Knoten die gespeicherten Blöcke bei deren Weitergabe nicht identifizieren kann, wird nicht einfach entschlüsselt und dann neu verschlüsselt. Es wird vielmehr immer eine, sich aber mit der Zeit ändernde, Verschlüsselungsschicht belassen, damit ein Block nur vom wahren Downloader komplett entschlüsselt werden kann.

- Weil die Blöcke sich dauernd verändern, der Anforderer aber diese ja auch irgendwie auffinden muss, wird ein komplexes Blockverwaltungssystem benötigt.

- In diesem System werden die Blöcke durch eine gewisse Anzahl von Tickets identifiziert.

- Je höher die Anzahl Tickets pro Block festgelegt wird, desto grösser wird die Anonymität sein.

- Ein Knoten hält jeweils nur ein Ticket pro Block.

- Ein sehr strenges und aktives DHT-Regime (z.B. XOR-Metrik) sorgt dafür, dass die Tickets immer am richtigen Ort sind. Damit wird nicht nur bezweckt, dass die Tickets immer schnell auffindbar sind. Sondern das Ganze dient auch und vor allem der Abwehr von Attacken durch Honey-Nodes mittels Honey-Files. Ohne in die Details zu gehen: Ein System der gegenseitigen Kontrolle sollte verhindern, dass etwa ein Uploader (oder Tickethalter-Knoten, die zufälligerweise einem Angreifer gehören) alleine über den Aufenthaltsort der Tickets entscheiden kann. Vielmehr werden die Knoten gezielt (aber zufällig) aufgrund ihrer IP-Adressen ausgewählt.

- Das Blockverwaltungssystem ist dynamisch und dementsprechend kurzlebig (ich nenne es "active housekeeping"). D.h. ein Knoten speichert in der Zeit, während der er "up" ist, laufend Tickets und gibt diese auf Anfrage weiter. Geht ein Knoten offline, so werden die Tickets nicht etwa gespeichert, sondern gehen verloren.

- Damit ein Block dennoch adressierbar bleibt, gibt es ingesamt mehr Tickets (mind. 1 Ticket mehr) als für die Identifikation eines Blocks benötigt werden.

- Geht ein Knoten, der ein bestimmtes Ticket gehalten hat, offline, sorgen die anderen Knoten schnellstmöglich dafür, dass aus den bestehenden Tickets ein neues (Ersatz)ticket generiert wird und dieses auf einem zufällig gewählten Knoten ein neues vorübergehendes Zuhause erhält.

- Bei diesem Vorgang werden die verbleibenden Tickets neu randomisiert. D.h. es wird ihnen eine Schicht "random noise" hinzugefügt, die sich aber beim Zusammenführen aller Tickets wieder von selbst aufhebt ("XOR" lässt grüssen ;)).

- Dies sollte verhindern, dass ein Angreifer über längere Zeit unerkannt Tickets sammeln kann. Denn nach jedem Knotenwechsel werden die Karten quasi neu gemischt.

- Für den gleichen Zweck ist vorgesehen, dass ein Knoten ein Ticket nur während einer bestimmten Zeit halten darf (z.b. 1 Stunde). Danach muss er es weitergeben.

- Obschon ein Ticket für sich alleine über den Datenblock noch nichts aussagt, enthält es andererseits als Information den Hashwert des Datenblocks in seiner unverschlüsselten Form (Originalblock ID). Da nun diese Originalblock IDs in URLs resp. Deskriptorenblöcken aufgeführt sind, kann jeder Knoten, der ein Ticket hält, theoretisch herausfinden, welcher logische Inhalt (Datei) damit referenziert wird.

- Aus diesem Grund darf die Kommunikation zwischen dem Downloader (als Ticket-Anforderer) und den Tickethaltern nicht direkt stattfinden. Ansonsten wüsste jeder Tickethalter sogleich, hinter welchem Block ein Downloader her ist.

- Stattdessen werden Tunnels verwendet, wie man sie vom Onion-Routing her kennt.

- Im Unterschied zu TOR, aber in Analogie zu I2P, kann dabei End-To-End-Encryption wirksam eingesetzt werden, weil der Downloader einen beliebigen Knoten, mit dem er jemals etwas zu tun hatte (und er mit ihm deshalb bereits die Public-keys ausgetauscht hat) als Exit-Knoten bestimmen kann. Damit sind Man-in-the-Middle-Attacken undenkbar.
Der Exitknoten kann dann die Ticket-Anfrage vollständig entschlüsseln, und so den/die Ticket-Halter mittels der DHT auffinden. Er  überprüft anhand der IP und der aktuellen Uhrzeit die Legitimation des jeweiligen Ticket-Halters und fordert im positiven Fall das Ticket an.

- Um eine hohe Sicherheit zu gewährleisten, sollte jedoch nicht ein einziger Exit-Knoten sämtliche Tickets anfordern (er könnte ja evtl. mit feindlichen Tickethaltern kollaborieren), sondern jedes Ticket sollte über ein separates Tunnel angefragt werden.

- Haben die Tickethalter eine Anfrage erhalten, geben sie die Ticket ausserdem nicht sofort heraus. Vielmehr veranlassen sie vorher zuerst eine Duplizierung des referenzierten Blocks, damit dieser durch den späteren Download nicht für immer untergeht. Wie gesagt werden Blöcke nach einmaligem Download ja sofort gelöscht!

- Da sich der zu duplizierende Block erst auffinden lässt, sobald alle Tickets in einer Hand (die ja "schmutzig" sein kann) vereinigt sind, können nicht einfach alle Tickethalter ihre Tickets einem Drittknoten übergeben. Denn dieser könnte ja auch dem Feind gehören. Aus diesem Grund wird ein spezielles pyramidenförmiges Routing-Verfahren eingesetzt sowie "random noise", der sich schlussendlich an der Pyramidenspitze wieder von selbst aufhebt. Ausserdem wären künstliche Latenzen von Vorteil, um Timing-Attacken zu vereiteln.

- Gerade wegen dieser Attacken wäre es auch zu riskant, eine Bestätigung der Duplikation den gleichen Weg zurückzuschicken. Am besten wird auf eine solche Bestätigung ganz verzichtet und die Tickets ohne weiteres durch die Tunnels an den Anfrager geleitet.

- Eine Kontrolle kann nämlich durch den Inhaber des Blocks selbst durchgeführt werden: Denn dieser kann ja zwischen einer normalen Blockanfrage und einer Duplikationsanforderung unterscheiden. Erhält er also eine Blockanfrage, ohne vorher den Block dupliziert zu haben, lehnt er den Blocktranfer einfach ab und gibt dem Downloader eine entsprechende Notiz. Letzterer kann die Notiz dann (wieder durch die Tunnels) zu den Tickethaltern weiterleiten, damit diese die Duplikation erneut veranlassen können.

Funktionsweise (Insert von Blöcken)
- Im Gegensatz zum Download gibt es zum Insert nicht viel zu sagen. Der Uploader muss den Block nämlich lediglich verschlüsseln und kann ihn an einen beliebigen Knoten (ev. ausgewählt nach Effizienzfaktoren) schicken.

- Danach generiert er zunächst selber sämtliche Tickets für den Block und schickt diese via Tunnels an die passenden Knoten.

- Hier ist wieder sehr wichtig, dass sich die Tickethalter-Knoten stets gegenseitig überwachen und dafür sorgen, dass immer die gemäss DHT passendsten Knoten ein Ticket besitzen.

- Selbst wenn also ein Feind als Honey-File-Uploader seine Komplizen für den Tickethalter-Posten auswählen könnte, wird ihm das nichts bringen: Denn bei späteren Ticketanfragen überprüfen die Exit-Knoten wie gesagt die Legitimation der Tickethalter.
Auch bei einer Ticket-Rotation aufgrund Zeitablaufs oder wegen offline-Gehens eines Knotens finden durch die neu angefragten Ticekthalter-Knoten solche Kontrollen statt. Nur wenn es der Feind also schafft, zu einer gegebenen Uhrzeit zu einem zufälligem Hashwert von sämtlichen n Knoten im Netz c Knoten zu besitzen, deren IP gehasht die geringste Hamming-Distanz zum eben genannten Wert aufweist, kann ein kompletter Satz von Tickets und damit ein Block als kompromittiert gelten.

- Damit der Uploader auch anonym bleibt und um die erwähnten Honey-File-Attacken gänzlich zu unterbinden, darf ein eingefügter Block nicht sofort für den Download freigegeben werden. Erst wenn er ein paar Mal (z.B. 3 Mal) dupliziert wurde (es werden immer die Duplikate für die weiteren Duplikationen verwendet), wird er für den eigentlichen Download freigegeben.

- Über die Anzahl der Duplikationen führen sämtliche Tickethalter peinlichst genau Buch. Die Identität der Knoten, die den Block auf diesem Weg erhalten, bleibt vor ihnen jedoch verborgen.

- Nur wenn der Feind sämtliche Knoten der "Duplikationskette" kontrolliert und sich später herausstellt, dass der gehaltene Block zu einer verfolgten Datei gehört, kann der Downloader rückwirkend enttarnt werden, aber nur wenn der Feind natürlich alles fein säuberlich protokoliert hat.



Ich hoffe, dass ich damit einen einigermassen verständlichen Überblick über CMIYC geben konnte.
Der Teufel steckt aber im Detail und eine wirklich umfassende Darstellung werde ich, bei Bedarf, in Form eines Aufsatz veröffentlichen. Wann das geschehen wird, ist aber noch offen.

Offline Eroli

  • Elite
  • *****
  • Posts: 2435
  • Karma: +22/-0
  • StealthNet Developer
    • View Profile
Re: Die perfekte anonyme Tauschbörse
« Reply #12 on: April 25, 2008, 09:35:13 PM »
Das ganze hört sich SEHR (!!!!!!!) kompliziert an, wenn auch nicht uninteressant. Mich würde eine Ausarbeitung schon interessieren, obgleich ich dich nicht mit zuviel Arbeit belasten möchte, wenn ich der einzige bleibe. Ich bin mir auch nicht sicher, ob ich dir bei der weiteren Ausarbeitung helfen könnte, zur Zeit bezweifel ich das eher.

Offline SupersurferDeluxe

  • Elite
  • *****
  • Posts: 446
  • Karma: +21/-7
    • View Profile
Re: Die perfekte anonyme Tauschbörse
« Reply #13 on: April 26, 2008, 06:32:28 AM »
@hummel
Ich finde, es hört sich komplex, aber schlüssig an! Denke, ich habe alles verstanden und bin sehr angetan!

Wie du schon geschrieben hast: der Teufel steckt im Detail und der konkreten Umsetzung deiner Ideen und Prämissen und daher wäre auch ich sehr an einer detaillierteren Ausarbeitung interessiert. Dein Augenmerk sollte meiner Meinung nach dabei NICHT darauf liegen, es möglichst "einfach und für alle verständlich" zu erklären, sondern einfach nur noch etwas konkreter/detaillierter - da mußt du glaube ich gar nicht SOOO riesig viel mehr ausholen und Arbeit reinstecken wie für dieses Posting. Ich denke das Konzept ist jedem einigermaßen intelligenten und vor allem AUFMERKSAMEN und INTERESSIERTEN Leser deines Postings verständlich. Natürlich kostet diese gebotene Aufmerksamkeit viel Zeit beim Leser (zumindest war es so bei mir eben) und auch die Motivation sich Textabschnitte mehrmals zu Gemüte zu führen. Jedoch: Ernsthafte und erkenntnisgewinnbringende Kommentare kannst du wahrscheinlich eh nur von solchen Leuten erwarten, die auch bereit sind diesen Verständnis- und Zeitaufwand zu leisten. Vielleicht leistet dein Text daher eine "gute" Selektion bei den Kommentatoren...  ;)


Nun konkret: habe mir einige anonymitätsgefährdende Szenarios durchüberlegt und muß sagen, dass alle deine Kriterien/Eigenschaften des Netzwerkes gut durchdacht sind und spätestens beim Durchspielen einiger Szenarios auch in Sinn und Zweck völlig klar werden. Mir sind jedenfalls alle angeführten Punkte einleuchtend. Das Zusammenspiel und das Abklopfen auf Schwächen ist allerdings dann doch komplexer zu leisten, und nicht bei nur einer einmaligen Beschäftigung damit.

Details, z.B. wie du sicherstellst, dass ein Blockdownload nur einmal stattfindet und dann nicht mehr, kombiniert mit einer begrenzten Zeitdauer der Tickethaltbarkeit und dergleichen mehr, lassen mich befürchten, dass entweder die Anonymität an diesen Stellen gefährdet wird oder viel wahrscheinlicher (wenn ich mir denke welchen kreativen Hirnschmalz du schon für deine Idee verbraten haben mußt) das Netz damit Angriffspunkte zur massiven Störung bieten wird. Hier mag ich doch gern noch ein ausführlicher dargelegtes Konzept diskutieren und dich bitten diesen Aufwand zu betreiben.


Nur bei einem Punkt möchte ich dir spontan widersprechen:
Quote
Nur wenn es der Feind also schafft, zu einer gegebenen Uhrzeit zu einem zufälligem Hashwert von sämtlichen n Knoten im Netz c Knoten zu besitzen, deren IP gehasht die geringste Hamming-Distanz zum eben genannten Wert aufweist, kann ein kompletter Satz von Tickets und damit ein Block als kompromittiert gelten.

Ich sehe eine mögliche Komprimittierung auch dann, wenn der Feind zugleich als Downloader einen "Blockuploadpartner" durch das Ticketsystem zugewiesen bekommt und er auch diesen "Blockuploadpartner" (als verbündeter Feind) unter Kontrolle hat - alles nur eine Frage der Zeit und der eingesetzten Ressourcen, bis dies passiert. Jetzt kann man in den Logs den Uploader des nun eindeutig identifizierten Blocks ausfindig machen -> zumindest Störerhaftung wäre denkbar.
Außerdem wäre es möglich, dass man bei der Duplizierung (ich gehe mal davon aus, dass das einmalige downloaden fremdkontrolliert und nicht manipulierbar über die Tickets läuft, sonst gehts natürlich noch einfacher an dieser Stelle*) WIEDER irgendwann bei einem so identifizierbaren Block zufällig zu einem verbündeten feindlichen Client hochlädt. DIESER hat dann die Möglichkeit den nächsten Downloader eindeutig als "Content-Räuber" dingfest zu machen...
Allerdings wären die "Kosten" ziemlich hoch: dieser Fall ist nicht sehr wahrscheinlich und bis er eintritt wird das Netz supported. Das kann der Content-Mafia keinen Spaß machen...

*andererseits bietet dies dann wieder mögliche Netzschädigungsszenarien in meiner Phantasie.

Das größte Problem sehe ich im Overhead, der sehr hoch sein wird und deshalb zur Downloadeffizienzsteigerung die großen Datenblöcke nötig macht, was wiederum zusätzlich den Upload beim ständigen Duplizieren völlig zumachen könnte, je größer der verfügbare Inhalt im Netz (Skalierung). Irgendwie hab ich das Gefühl, dass dadurch der direkte Download ineffektiv wird (zumindest bei den immer noch vorherrschenden asynchronen Internetzugängen) und es VON DER GESCHWINDIGKEIT letztlich egal ist, ob Systeme wie Stealthnet oder dieses verwendet werden. Die Anonymität ist aber zweifelsohne bei deinem System deutlich besser gelöst. Ich rechne mal durch das Duplizieren mit der Hälfte des zur Verfügung stehenden Uploads und dann muß man noch den ziemlich deutlichen Overhead abziehen und ich meine nochmal die Hälfte durch künftig zu erwartende Netzwerkstörungsversuche. Letztere sehe ich als größtes Problem: eventuell viele mögliche Angriffspunkte, um das Netz mit überflüssigen Verwaltungs- / Verschlüsselungs- / Entschlüsselungsaufgaben zu bombardieren und Overhead zu verursachen oder zumindest Rechnerleistung für irgendwelche Blacklists und Prüfungen/Berechnungen aufzubringen.

Trotz einiger Befürchtungen: das Konzept ist heiß, SEHR HEISS! Es wäre toll, wenn es dazu irgendwann ein ausfühlicheres Paper und dann mal ne Software dazu geben würde. Endlich mal Sicherheitsaspekte berücksichtigt, die mir gefallen.
OFF ist bisher mein Favorit, aber ich bin nicht 100% überzeugt...

Offline hummel

  • Elite
  • *****
  • Posts: 429
  • Karma: +12/-0
    • View Profile
Re: Die perfekte anonyme Tauschbörse
« Reply #14 on: April 27, 2008, 08:35:50 PM »
Ich finde, es hört sich komplex, aber schlüssig an! Denke, ich habe alles verstanden und bin sehr angetan!
...
Trotz einiger Befürchtungen: das Konzept ist heiß, SEHR HEISS! Es wäre toll, wenn es dazu irgendwann ein ausfühlicheres Paper und dann mal ne Software dazu geben würde. Endlich mal Sicherheitsaspekte berücksichtigt, die mir gefallen.
Es freut mich das zu hören! Und zudem bin ich dir dankbar, dass Du meinen Beitrag durchgelesen und offenbar auch verstanden hast.
Allerdings muss ich gleich zu Beginn für Ernüchterung sorgen: Denn CMIYC steckt noch ganz am Anfang und bis zur Praxistauglichkeit ist noch ein LANGER Weg. Trotzdem denke ich, dass das Konzept unter gewissen Voraussetzungen machbar wäre.

Zwei meiner grössten Sorgenkinder sind - wie Du auch schon bemerkt hast - die Robustheit des Systems gegen DoS-Attacken jeglicher Art und der konstante Overhead, der durch das Ticketverwaltungssystem entsteht.

Zum ersten Problem werde ich dich wohl (vorerst) enttäuschen müssen: Denn die Robustheit werde ich in meinem ersten Entwurf noch sicher nicht berücksichtigen können. Ganz bewusst habe ich mir dazu noch nicht viele Gedanken gemacht, da unbedachte Lösungsvorschläge (und sei es nur eine kurze Rückmeldung/Bestätigung einer Aktion) fast immer eine Gefahr für die Anonymität darstellen. Und letztere geniesst für mich zumindest im Moment eine höhere Priorität.

Ich weiss nicht, ob Dir die Entstehungsgeschichte des Dining-Cryptographers-Protokolls bekannt ist. David Chaum, der geistige Vater dieser trivialen aber genialen Idee, hat sich nicht damit begnügt, ein beweisbar anonymes Kommunikationssystem vorzustellen. Vielmehr lieferte er gleich zu Beginn ein Protokoll, welches auch DoS-Attacken abwehren konnte. Nun, letzteres wurde ihm zum Verhängnis, als 1989 Pfitzmann et al. entdeckt haben, dass sich das Abwehrsystem selbst missbrauchen lässt, so dass am Schluss die Anonymität der Teilnehmer keineswegs mehr gesichert ist. Diesen Fehler möchte ich selber nicht auch begehen! ;)
Meiner Meinung nach sollte man die Robustheit daher erst in einem zweiten Schritt angehen und immer peinlichst genau auf etwaige negative Auswirkungen von Sicherungsmassnahmen achten.

Bezüglich Verwaltungsoverhead bin ich zuversichtlich, dass hier noch sehr viel Verbesserungspotential besteht. Wahrscheinlich wäre es von Vorteil, wenn für eine grössere Zahl von Tickets immer dieselbe Gruppe von Knoten verantwortlich wäre. Allenfalls wäre es sogar sinnvoll, die Tickets für sämtliche Blöcke der gleichen Datei bei den gleichen Tickethaltern zu "parkieren". Natürlich immer unter der Voraussetzung der ständigen gegenseitigen Kontrolle und periodischer Rochaden. Auf diese Weise könnte man ganz viel Overhead einsparen: Ist nämlich ein Knoten gleichzeitig nur an wenigen "Tickethalter-Gruppen" beteiligt, so muss die Legitimation (Bsp. hash(IP-Adresse) mit der kürzesten Distanz zu hash(Ticket ID + verstrichene Stunden)) von höchstens ein paar Dutzend Knoten überwacht werden.

Damit könnte man sehr viel Aufwand einsparen. Denn ins Gewicht fallen werden vorderhand nicht diejenigen Aktionen, die durch eine Ticketanfrage ausgelöst werden, sondern jene, die laufend stattfinden müssen. Wenn nur alle paar Minuten eine Ticketrochade wegen Offline-Gehens eines Knotens resp. Entdeckung eines neuen Knotens mit noch besserer Legitimation stattfinden muss, dürfte sich der Overhead insgesamt in Grenzen halten. Zwar müssen dann auf einmal z.B. 100 Tickets weitergegeben (besser gesagt: aus den vorhandenen rekonstruiert) und randomisiert werden. Jedoch wird ein Ticket nur einige 100bytes (ev. wenige kbytes) umfassen, was das ganze wieder erträglicher macht.

Quote
Nun konkret: habe mir einige anonymitätsgefährdende Szenarios durchüberlegt und muß sagen, dass alle deine Kriterien/Eigenschaften des Netzwerkes gut durchdacht sind und spätestens beim Durchspielen einiger Szenarios auch in Sinn und Zweck völlig klar werden. Mir sind jedenfalls alle angeführten Punkte einleuchtend. Das Zusammenspiel und das Abklopfen auf Schwächen ist allerdings dann doch komplexer zu leisten, und nicht bei nur einer einmaligen Beschäftigung damit.
Wie gesagt, es gibt noch VIEL zu tun.

Quote
Nur bei einem Punkt möchte ich dir spontan widersprechen:
...
Ich sehe eine mögliche Komprimittierung auch dann, wenn der Feind zugleich als Downloader einen "Blockuploadpartner" durch das Ticketsystem zugewiesen bekommt und er auch diesen "Blockuploadpartner" (als verbündeter Feind) unter Kontrolle hat - alles nur eine Frage der Zeit und der eingesetzten Ressourcen, bis dies passiert. Jetzt kann man in den Logs den Uploader des nun eindeutig identifizierten Blocks ausfindig machen -> zumindest Störerhaftung wäre denkbar.

Außerdem wäre es möglich, dass man bei der Duplizierung (ich gehe mal davon aus, dass das einmalige downloaden fremdkontrolliert und nicht manipulierbar über die Tickets läuft, sonst gehts natürlich noch einfacher an dieser Stelle*) WIEDER irgendwann bei einem so identifizierbaren Block zufällig zu einem verbündeten feindlichen Client hochlädt. DIESER hat dann die Möglichkeit den nächsten Downloader eindeutig als "Content-Räuber" dingfest zu machen...

Hier hast Du eine wichtige Schwachstelle erkannt, die mein oben vorgestelltes Konzept tatsächlich aufweist. Leider hab ich vergessen zu erwähnen, dass die Beschreibung nur eine Vereinfachung des eigentlichen Modells (resp. der Modelle) darstellt. Ich wollte euch nämlich für den Anfang nicht noch mehr Einzelheiten zumuten.
Da ich aber jetzt sehe, dass Interesse besteht, werde ich zum Konzept noch einige wichtige Präzisierungen geben:

Definitionen:
- n: Anzahl aller Knoten im Netz

- c: Anzahl feindlicher (kollaborierender) Knoten

- Kontrollknoten: Derjenige* zufällige Knoten, der als "Spitze der Pyramide" (Pyramidenrouting) von den Tickethaltern sämtliche Tickets eines bestimmten Blocks, die dazugehörigen Schlüssel und sonstige Anweisungen erhält. Er kennt zwar die Kennung des verschlüsselten Blocks, kann aber den darin verborgenen Inhalt nicht identifizieren. Auch dann nicht, wenn er einen (oder mehrere) Tickethalter als Komplizen hat. Die Tickethalter leiten nämlich nur denjenigen Teil ihres Tickets (sozusagen die "Rückseite") an ihn weiter, der eben diesen verschlüsselten Block kennzeichnet.
Natürlich kann ein Kontrollnode die Anweisungen missachten und den betreffenden Block auf einem anderen als dem angegebenen Knoten duplizieren. Damit wird das Duplikat unansprechbar, weil die Tickethalter das nächste Mal auf den eigentlich vorgesehenen Knoten verweisen werden. So können feindliche Kontrollknoten zwar an zufälligen Orten Schaden anrichten, nicht aber die Anonymität gefährden.

*Allenfalls wäre es vorteilhaft mehrere Kontrollknoten für eine Downloadanfrage auszuwählen. Eine bestimmte Art von Attacke, auf die ich jetzt nicht eingehe, könnte damit verhindert werden.

Wenn ich Dich richtig verstanden habe, hattest Du das folgende Threat-Szenario im Kopf:



Falls wir davon ausgehen, dass die Tickethalterknoten sowie die Pyramide mit dem Kontrollknoten an der Spitze nicht kompromittiert sind, beträgt die Wahrscheinlichkeit für den aufgezeigten Angriff (c/n)^2. Es müssen ja genau zwei feindliche Knoten in einer Serie liegen.
Bei 20% feindlichen Knoten also 4%. Das ist natürlich ziemlich schlecht. Das vereinfachte Modell, wie ich es oben ausgeführt habe, leidet aber auch an anderen Schwächen: Z.B. ist keine Redundanz gewährleistet, weil ja immer nur eine Duplikation pro Anfrage erfolgt. Und bei der Anfrage wird der Block vom sendenden Knoten anschliessend immer gelöscht. Das ganze ist also ein Null-Summen-Spiel.
Somit ist diese Lösung sowohl aus Sicherheitsgründen- als auch aufgrund von Effizienzproblemen nicht gerade optimal.

Die beste Lösung, die ich für meine Zielvorgabe "Enttarnung mit höchstens (c/n)^3" gefunden habe, sieht wie folgt aus.
 
Ausgangssituation:
Der ursprüngliche Inserter (Uploader) hat den Block auf einen zufälligen (durch die Ticketinhaber mitbestimmten) Knoten übertragen und die Tickets entsprechend eingerichtet. Dieser Block ist vorerst der einzige im Netzwerk, der enstschlüsselt den Originalblock ergibt.

Anstatt dass wir nun pro Anfrage irgendeinen der vorhandenen Blöcke duplizieren und einen anderen Block dem Downloader zum Herunterladen geben, wenden wir eine ausgeklügeltere Strategie an. Wir nehmen uns vor, dass ein Block ingesamt betrachtet immer über mindestens drei Hops zu einem der Downloader- resp. dem ursprünglichen Inserterknoten führen muss. Das ergibt sich aus der Zielvorgabe.

Der erste, der unseren Block downloadet, muss ihn also über zwei Mittelsmänner holen. Der Kontrollknoten gibt demnach dem ersten Blockinhaberknoten die Anweisung, den Block an Knoten 1 zu übermitteln und Knoten 1 die Anweisung, den erhaltenen Block an Knoten 2 zu schicken. Schliesslich wird Knoten 2 der Auftrag gegeben, den Block dem Downloader weiterzusenden. (Verwendet man - wie oben erwähnt - mehrere Kontrollknoten, so wäre jeder nur für einen dieser Transfers verantwortlich.)



Man kann also sogar darauf verzichten, dem Downloader die Tickets zu geben, damit er sich den Block vom letzten Knoten selber "abholen" kann. Denn der Downloader kann seine Identität/IP-Adresse in Teile zerlegen und den Tickethaltern je einen Teil schicken. Erst beim Kontrollknoten, der den verschlüsselten Block aber keinem logischen Inhalt zuordnen kann, ergibt sich ja die wahre Identität des Downloaders. Da sich allerdings in der Pyramide selbst auch feindliche Knoten aufhalten können, sollte eine genügende Anzahl von Tickethaltern als Basis vorhanden sein. Nach meinen Berechnungen/Simulationen sollten 5 Tickethalter bei 10% feindlichen Knoten resp. 6 bei 20% schon eine recht hohe Sicherheit bieten.
 
Liesse sich das Ticketverwaltungssystem wie oben angetönt rationalisieren und sorgt man zudem für genügende Redundanz (z.B. 2-3 Ersatzmänner pro z.B. 10 Tickethalter), so spräche aus Performancegründen nichts dagegen, eine noch höhere Zahl an Tickethaltern einsetzen. Denn dann könnte man rein theoretisch in einem Durchgang alle (oder zumindest mehrere) Blöcke einer Datei abarbeiten. Der Downloader könnte in einem zweiten (dritten, vierten, ..) Schritt diejenigen Blöcke nochmals gezielt anfordern, welche ihm noch fehlen. Denn natürlich werden nicht immer alle Blockinhaber gerade online sein. Selbst eine Statistik mit der uptime-ratio der Blockinhaber könnte durch die Ticketinhaber geführt werden und für die Effizienz für künftige Anfragen verbessern. Hier gibt es aber noch viel zu tun. ;)

Aber zurück zum eigentlichen Thema...

Durch die Neuverschlüsselung wird eine Identifikation des Blocks auch in der Situation verhindert, in denen sowohl der Blockinhaberknoten als auch Knoten 2 (nicht aber Knoten 1!) vom Feind kontrolliert werden.

Im Unterschied zu meinem vereinfachten Konzept, werden hier auch keine Blöcke gelöscht. Es wird somit nicht mehr zwischen Downloadanfragen und Duplikationsanfragen unterschieden. Stattdessen gilt ein Klassensystem: Es gibt Blöcke 1. und 2. Klasse. Ein erstklassiger Block kann bereits über einen Hop heruntergeladen werden, ein zweitklassiger nur über zwei.
Die Klassenzuteilungen der Inhaberknoten werden durch die Tickethalterknoten protokolliert. Letztere kennen die Identität der Inhaberknoten natürlich deswegen immer noch nicht, weil sich diese erst durch das Zusammenlegen der Tickets ergibt.

In unserem Beispiel wäre Knoten 1 erstklassig und Knoten 2 zweitklassig.

Erstklassige Knoten werden bei späteren Downloadanfragen favorisiert, da sie nur 100% Overhead verursachen.
Nach einem weiteren Download des Blocks könnte die Topologie wie folgt aussehen (Zahl bei den Knoten = Klasse):



Nur in zweiter Linie geben die Tickethalter also zweitklassige Knoten bekannt, d.h. jeweils dann wenn gerade keine erstklassigen verfügbar sind. Dann könnte sich die Situation z.B. so darstellen:



Immer beträgt die kürzeste Verbindung zwischen zwei Downloadern 3 Hops. Egal wo sich also ein Downloader an die Topologie "dranhängt", die Enttarnungswahrscheinlichkeit entspricht immer der obigen Zielvorgabe. Korrigiert mich bitte, wenn ich damit falsch liege. :)

Wichtig ist noch zu erwähnen, dass zweitklassige Knoten den Block nur dann speichern, falls sie noch freien Speicherplatz in ihrem Cache haben. Dazu teilt der Kontrollnode in seiner Anweisung den Knoten ihre jeweilige Klasse mit. Für die erstklassigen Knoten/Blöcke könnte man sogar vorsehen, dass sie bei vollem Cache zweitklassige Blöcke "hinausdrängen" können.

Wenn zweitklassige Knoten einen Block nur in manchen Fällen speichern, hat das auch juristische Vorteile. Ein feindlicher Downloader, welcher stets nur mit zweitklassigen Knoten in direkten Kontakt treten kann, kann nicht wissen, ob der Block vom Absender auch tatsächlich gespeichert wurde. Eine Haftung als Hostingprovider würde wegen Beweislosigkeit scheitern. (Natürlich könnte aber eine Mitstörerhaftung als Durchleiter dessenungeachtet bestehen)

Wenn ich davon ausgehe, dass ein häufig angefragter Block sich stark ausbreitet und irgendwann genügend erstklassige Blockinhaber vorhanden sind, sollte sich ein Overhead von 100% einpendeln. Auch weitere Spielarten, z.B. ein Zufallsfaktor in der Wahl der Hop-Länge (wie bei I2P) liessen sich realisieren.

Das Optimum wäre erreicht, wenn man sagen könnte:
Selbst ein Feind, der einen erheblichen Teil der Knoten kontrolliert, kann zwar manchmal ganz vereinzelte Blockanfragen ausspionieren (mit einer Wahrscheinlichkeit gemäss Zielvorgabe). Eine solche Beobachtung liefert aber wegen der variablen Hoplänge nur eine Erfolgswahrscheinlichkeit von z.B. 33 oder 50%, was für sich genommen noch nicht ausreichend ist. Um einen Verdacht zu erhärten, müsste man deshalb den gleichen Knoten mehrere Male (bei verschiedene Anfragen betreffend Blöcke der gleichen Datei) erfolgreich ausspionieren. Und das gelingt nur mit einer verschwindend geringen Wahrscheinlichkeit.

Ausbeute des Konzepts im Vergleich zu I2P:
Wenn wir sowohl bei CMIYC und I2P auf Zufallsfaktoren in der Hop-Länge verzichten und vom Ticketverwaltungsoverhead absehen (ich weiss, ich weiss...), können wir folgendes festhalten:

- Bei CMIYC wird der Overhead wohl irgendwo zwischen 100 und 150% liegen. Eine Enttarnung (von kompromittierten Tickethaltern und dgl. mal abgesehen) wäre mit einer Wahrscheinlichkeit von (c/n)^3 möglich.

- In I2P hat man - so weit ich das überblicke - für jede Anfrage eines Datenpakets zwei separate Tunnels, einen Outbound- und einen Inbound-Tunnel. Der Outbound-Tunnel schützt nur den Uploader, der Inbound-Tunnel nur den Downloader, denn es ist für einen Angreifer ohne weiteres möglich, einen vollständig kompromittierten Tunnel bekannt zu geben. Wenn ich mal davon ausgehe, dass ein einzelner Tunnel konstant aus 2 Knoten besteht, so hat man letzten Endes einen Overhead von 400%. Den Tauschpartner kann man aber schon mit einer Wahrscheinlichkeit von (c/n)^2 enttarnen.
Vgl. http://www.i2p2.de/how_tunnelrouting

Wenn all diese Annahmen tatsächlich zutreffen und man es irgendwie schafft, den ganzen Verwaltungskram effizient zu lösen, hätte man mit CMIYC ein System, das wesentlich effizienter und zugleich deutlich sicherer ist als I2P.
Aber genug der Schwärmereien!

Es müssen ja noch 1000 Dinge bedacht und auch ausgearbeitet werden. Und Probleme (z.B. rund um die Robustheit) werden sich noch genug stellen.


« Last Edit: April 30, 2008, 08:16:18 AM by hummel »