Ähnliche Ziele, verschiedene Wege: Freehaven & GNUnet

Ähnliche Ziele, verschiedene Wege: Freehaven & GNUnet Sam Joachim joachim@informatik.hu-berlin.de Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Vergleich & Einschätzung Der Rohbau Definition von Anonymität Realisierung Realisierung Design Design Anforderungen Anforderungen Freehaven GNUnet Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Agenda • Begriffserklärung • Definition von Anonymität • Freehaven • Idee & Anforderungen • Design & Umsetzung • GNUnet • Idee & Anforderungen • Design & Umsetzung • Vergleich • Projektvortschritt • Vor/Nachteile der „Kontrahenten“ Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Grundlegende Begriffe • Agenten in P2P-Systemen: • Publisher möchten Dokumente auf einem Server (und damit im P2P-System) speichern, um verschiedene Lesern den Zugriff zu ermöglichen • Servnet Verbund von Servern Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Formen der Anonymität Anonymität für • Autoren • Publisher • Leser • Server • Dokumente • Abfrage Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Author, Publisher & Reader Anonymity • Anonymität  das Verbergen des wahren Namens und des Standortes • Ein P2P System hat Autoren, Publisher oder Leser Anonymität, wenn es keine Möglichkeit gibt, ein bestimmtes Dokument mit den einzelnen Rollen in Verbindung zu bringen. Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Server Anonymity • Server kann nicht mit einem bestimmtes Dokument in Verbindung gebracht werden • oder: aus der Identifikation eines Dokumentes kann nicht auf den Speicherort geschlossen werden Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Document Anonymity • Server hat keine Kenntnis von den auf ihm gespeicherten Dokumente • sehr wichtiger Bestandteil beider Architekturen (hauptsächlich zum Schutz der Server-Betreuer) Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Query Anonymity • Server kann nicht identifizieren, welches Dokument (welche Anfrage) er ‚served‘, oder welchen Inhalt das Dokument hat • schwächere Form: ‚server deniability‘ • es kann nur mit einer gewissen Wahrscheinlichkeit festgestellt werden, was auf einem Server liegt Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Anforderungen an das Design • Operationen: • anonymes Einspielen von Dokumenten • anonymes Wiederauffinden und Echtheitsverifikation • Ablaufen von Dokumenten, d.h. löschen des Dokumentes bei Ende des beim Einspielen angegebenen Zeitraumes • Hinzufügen von Servern zum Netzwerk, ohne Beeinträchtigung der Funktion • Finden von inaktiven und ‚toten‘ Servern Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Guidelines 1 • Robustes System • kein Verlust von Dateien bei Ausfällen von etwa 50% der Server • Schaden von ‚bösen‘ Servern soll beschränkt werden (trust-net) • Einfachheit • komplexe Systeme laden Fehler ein  • Eigenständiges System basierend auf realistischen technischen Möglichkeiten. Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Guidelines 2 • Modularität • Dezentralisiertes System • Flexibilität • Open Source • Inhaltsneutralität • Popularität oder öffentliche Meinung soll nicht die Verfügbarkeit beeinflussen Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Bemerkung Effizienz ist bewußt nicht aufgeführt und wird zugunsten von stärkerer Anonymität ‚geopfert‘. Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Freehaven – Teile des Designs • Veröffentlichungsystem • verantwortlich für Speicherung und Bearbeitung • Kommunikationskanal • verantwortlich für die vertrauenswürdige und anonyme Kommunikation Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Kommunikation • im Moment über das Remailersystem Cypherpunks Remailer Network oder über MIX Remailer • ermöglicht das anonyme Versenden von e-Mails • sehr langsam, aber auch sehr sicher Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Das Servnet • jeder Server ‚beherbergt‘ Daten von anderen Servern im Austausch für die Möglichkeit, seine Daten ins Servnet einzustellen • Austausch = Handel • Servnet ist dynamisch • Daten bewegen sich von Server zu Server, basierend auf Zufall und Vertrauen Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Serverbestandteile • public key • einen oder mehrere Remailer-Blöcke von bekannten Servern • Datensätze über andere bekannte Server mit einer Einschätzung des Vertrauens zu ihnen Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Mixnet (Internet) Struktur des FreeHeaven Servers Comm Modul Node DB Haven Modul Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Publikation im FreeHeaven System • Dokument wird in f1, …, fn Teile (shares) zerteilt, von denen k beliebige shares zur Rekonstruktion ausreichen, jeder share bekommt einen ‚Buddy‘ • in jedem share: Zeitstempel, Buddy, Ablaufinformationen, PK, Anzahl und Nummer der Segmente, Signatur • Server generiert Schlüsselpaar (PKdok, SKdoc) • Server konstruiert und signiert Datensegmente für jedes fn und nimmt jedes share in seinen lokalen Speicher auf Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Anmerkungen zum Buddy • Aufgrund des implementierten Handelssystem, speziell zur Absicherung gegen feindliche Clienten, eingeführt • Jedes share ‚weiß‘ immer, oder sollte wissen, wo (auf welchem Server) sich sein Buddy befindet • weiteres später … Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Wiederauffinden der Dateien … • Indizierung durch Hash des Public-keys H(PKdoc) • Leser erzeugt Schlüsselpaar (PKclient, SKclient) und einen Einmal-Remailer-Antwortblock • Server sendet einen Broadcast nach H(PKdoc) zusammen mit Remailerblock und PKclient • jeder Empfänger testet, ob er einen Teil der Datei mit H(PKdoc) hat • jeden gefundenen Teil mit PKclient verschlüsseln, über den Remailerblock zurücksenden Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

H(PKdoc)PKclientOTRM E(PKclient)OTRM … in Motion ‚Bob‘ ? H(PKdoc) ‚Alice‘ PKclient, SKclient OT-Remailer Block ‚Chriss‘ ? H(PKdoc) ‚Dandy‘ ? H(PKdoc) Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Handel der Datensegmente • Warum? • Schutz des Publishers • Server können das System verlassen oder hinzukommen • wichtig für das Reputation System • längere Ablauffristen • moralischen Bedenken der Operatoren • ‚to provide a moving target‘ Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Ablauf des Handels • ‚Alice‘ wählt ‚Bob‘ und bietet sharex und fragt nach einem anderen share (Größe und Speicherdauer) • ‚Bob‘ ist interessiert, antwortet mit share y • Fairness beim Handeln basiert auf (Größe*Speicherdauer) • gegenseitiges zusenden der shares und von Belegen (receipts), auch zu den Buddies Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Receipts • beinhaltet: • Hash des PK vom Quellserver und vom Zielserver • Informationen über die zu gesendete und empfangene share traded • einen Zeitstempel • Hash des Dokumenten-Schlüssels • share Nummer, Ablaufdatum und Größe • Alle Informationen sind von A signiert. Falls sich B (oder ein anderer Server) eine Beschwerde sendet, ist dies ein erster, einfacher Beweis für A’s Unschuld. • ist kein Beweis für die Korrektheit der Transaktion, aber für die Hälfte einer Transaktion • Achtung: Handelssystem ist nicht ‘bullet-proof’, es existieren verschiedene Angriffspunkte Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Transfer Gitaw Transfer Tuney Receipt for Tuney Receipt for Tuney Receipt for Gitaw Receipt for Tuney Receipt for Gitaw Receipt for Gitaw Trade in FreeHaven ‚Alice‘ Gitaw ‚Bob‘ Tuney ‚Charlie‘ Gitax ‚David‘ Tunez Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Back to Buddies • Server sollen von Zeit zu Zeit die Existenz der Buddies ihrer shares überprüfen • Server sind für die korrekte Weiterleitung von diesen Prüfungen verantwortlich, falls das betreffende share den Server schon verlassen hat • wenn ein share verschwindet, wird der zuletzt verantworliche Server bekannt gegeben Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Reputation System • verantworlich für den Aufbau von Vertrauen • 2 wichtige Werte: • Ansehen (reputation) • Hält sich der Server an das FreeHaven Protokoll? • Glaubwürdigkeit (credibility) • Versendet der Server valide Daten? • Server sollten Empfehlungen unter bestimmten Umständen versenden: • erfolgreiches Beenden eines Handels • im Falle des Verlustes eines Buddies • bei gravierenden Änderungen von Ansehen und Glaubwürdigkeit Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Anforderungen an das Design • Anonymität für Benutzer • Deniability („Abstreitbarkeit“) für alle Teilnehmer • Dezentralisation • erst an 2ter Stelle Effizienz • Netzwerk belohnt Teilnehmer für ‚gutes‘ Verhalten •  dadurch kann z.B. das Routen von Anfragen hostspezifisch durchgeführt werden Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Guidelines 1 • Higher-Level-Protocols sollen bei Routing-Entscheidungen beteiligt werden • H-L-Ps entdecken Missbrauch und ‚belohnen / bestrafen‘ • Rechenzeit ist eine kritische Resource  Reduzierung des Verschlüsselungs-overheads für Server Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Guidelines 2 • GNUnet soll ‚wichtige‘ Inhalte von ‚Müll‘ unterscheiden können (Zugriffshäufigkeit) • Daten von ‚guten‘ Servern soll eine höhere Überlebenschance haben, als Daten von potentiel ‚bösen‘ Servern • Bearbeitung von Anfragen abhängig vom Ansehen des Servers Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Bemerkung Allerdings sind implizit die viele der Guidelines von FreeHaven auch hier gültig oder berücksichtigt. Zusätzlich wurde beim Entwurf berücksichtigt, dass GNUnet vielleicht über verschiedene Protokolle getunnelt werden könnte. Ein HTTP-Transport Dienst ist seit dem 26.5. als Beta verfügbar. In Planung: TCP, SMTP Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Aufbau • ein Server-Prozess • 3 Komandozeilen-Tools zum Einstellen, Suchen & Bewerten und runterladen • GUI geplant Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

GNUnet – Verteilte sichere Kommunikation • ähnlich zu SSH • 2-Schlüssel RSA für den Session-key • jede Node ist durch PK (oder H(PK)) identifiziert • aber: statt TCP wird UDP genutzt • TCP: overhead durch handshake, garantiert Reihenfolge der Pakete und Verlust • in GNUnet sind höherliegende Protokolle darauf nicht angewiesen • Vorteil von UDP: leichterer Einsatz von Strom-chiffrierern; wenig Protokoll-overhead Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Verwendete Algorithmen • RSA • gute Sicherheit, patentfrei • Blowfish • gedacht für SW-Implementation, frei, schnell • RIPE160 als Hash • längste Hashfunktion (Ausgabe) in OpenSSL • CRC32 als Checksumme für Daten • 32 bit in jeder iNode übrig, wenn jede 51 Hashes enthält  Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Effiziente Kommunikation • optimale Paketgröße: 1472 bytes (optimal für Ethernet) • Output wird für jede Zielnode gepuffert, um die Anzahl der Pakete niedrig zu halten • Heuristik, wem Daten gesendet werden sollen, ist nicht im Protokoll festgelegt Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Der erste Kontakt … • jede Node muss nicht nur den PK von anderen Nodes, sonder auch derzeitige IP und Port-Adresse kennen • beim Eintritt ins Netzwerk senden an alle bekannten Nodes diese Daten + Ablauf-zeitstempel in signierter HELO-Nachricht • HELO-Nachrichten werden zufällig an andere Nodes weitergeleitet Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Ranking • zum Schutz des Netzwerks • ‚böse‘ Nodes entdecken • ihren Einfluss minimieren • neue Nodes starten immer als ‚untrusted‘ • können Anfragen absenden, diese werden jedoch nur bei freien Kapazitäten beantworted Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Content Ranking • durch Nutzer • kann festlegen, wie wichtig der Inhalt ist • andere Nodes können je nach Vertrauen den Wert übernehmen, oder verringern • auf den Nodes • durch häufiges Anfordern wird das Ranking erhöht Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Publikation und Handel • Publikation: • auf einer Node werden neue Inhalte bereit gestellt • andere Nodes können gefragt werden, ob sie diese kopieren wollen • Handel • hierbei werden Teile zwischen Nodes gehandelt • vergrößert die Menge der vermutlichen Autoren Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Anfragen & Aufbewahrung • Indizierung durch Hash des Schlüsselwortes H(H(H(Keyword)) (Sicherheit) • Hashes können mit and, or und not kombiniert werden • Hashcodes werden in ‚indirection nodes‘ gruppiert (vergleichbar mit UNIX iNodes) • Unterscheidung zwischen Daten und MetaDaten schwierig • GNUnet stellt ‚on the fly‘ Verschlüsselung zur Verfügung Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

grafisch … • Zerlegen in 1k Blöcke B1 bis Bn • berechnen von H(B) und H(H(B)) • verschlüsseln von B mit H(B) • speichern unter H(H(B)) • nur 2% Overhead • eintragen in iNodes I1 bis Im • I = H(B1), … ,H(B51),CRC32(B1 • Inodes zusammenfassen • Rekursives Vorgehen  • Root-Inode mit Beschreibungen • mit Keywords verschlüsseln Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Projektvortschritt • Free Haven: • sehr theoretisches Projekt • letzte Newseintragung 15.08.02 • keinerlei lauffähige Versionen • GNUnet: • lauffähige Version 0.5.4 am 19.5. freigegeben (Linux) • GUI auch schon fertig Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Vorteile • Free Haven • Sehr gute Anonymität • Ablauf der eingestellten Daten • GNUnet • schnelle Kommunikation • gute Sicherheit bei geringem Overhead Seminarpräsentation "The Economics of Peer-to-Peer Architectures" von Sam Joachim

Ähnliche Ziele, verschiedene Wege: Freehaven & GNUnet