Systems Architecture Tarzan Dario Sait, Martin Schulze 10. Juli 2007.

Präsentation zum Thema: "Systems Architecture Tarzan Dario Sait, Martin Schulze 10. Juli 2007."—  Präsentation transkript:

1 Systems Architecture http://sar.informatik.hu-berlin.de Tarzan Dario Sait, Martin Schulze 10. Juli 2007

2 2 May 2006 - 2 Systems Architecture http://sar.informatik.hu-berlin.de Einführung ● Peer-to-peer Anonymisierung auf IP-Ebene ● Tarzan: Paket "hangelt sich" von Knoten zu Knoten

3 3 May 2006 - 3 Systems Architecture http://sar.informatik.hu-berlin.de Michael J. Freedman & Robert Morris Freedman (NYU, Stanford) & Morris (MIT)

4 4 May 2006 - 4 Systems Architecture http://sar.informatik.hu-berlin.de Grundlagen ● ein Netzwerkteilnehmer möchte mit einem beliebigen Server kommunizieren, ohne dass er identifiziert werden kann ● es wird von mehreren tausend Teilnehmern ausgegangen ● "neugierige" Teilnehmer befinden sich ebenfalls im gleichen Netzwerk

5 5 May 2006 - 5 Systems Architecture http://sar.informatik.hu-berlin.de Designziele ● Applikationsunabhängig ● Anonymität trotz Teilnahme böswilliger Knoten ● geringe Fehleranfälligkeit und hohe Verfügbarkeit ● hohe Performance ● Anonymität auch bei "großem Lauschangriff"

6 6 May 2006 - 6 Systems Architecture http://sar.informatik.hu-berlin.de Welche Möglichkeiten existieren bisher? ● anonymizer.com ● Onion Routing (TOR) ● Anonymous Remailer ●...

7 7 May 2006 - 7 Systems Architecture http://sar.informatik.hu-berlin.de Probleme und Gefahren ● Umgehen des Proxy ● Einbruch auf den Proxy ● DOS-Attacke ➔ Abhängigkeit von einem oder wenigen zentralen Instanzen

8 8 May 2006 - 8 Systems Architecture http://sar.informatik.hu-berlin.de Was gilt als bösartig? ● Pakete verändern ● unterschlagen ● speichern ● Analyse des Netzwerkverkehrs ● Rückgabe gefälschter Information ● jegliche sonstige Abweichung vom Protokollstandard

9 9 May 2006 - 9 Systems Architecture http://sar.informatik.hu-berlin.de Architektur und Design ● Überblick ● Pakete ● Tunnelaufbau ● Verbindung über den Tunnel ● Tunnelabbruch und Wiederherstellung ● Netzwerk kennenlernen ● Mimics ● Cover Traffic

10 10 May 2006 - 10 Systems Architecture http://sar.informatik.hu-berlin.de Überblick (1) ● Tarzan-Knoten soll: ● andere Knoten finden ● Pakete lokaler Anwendungen verschlüsseln ● Tunnel managen ● Pakete anderer Knoten im Tarzan-Netz weiterleiten ● Network Adress Translator (NAT) bereitstellen ● Schnittstelle an Internet

11 11 May 2006 - 11 Systems Architecture http://sar.informatik.hu-berlin.de Überblick (2) ● Pakete anonymisieren: ● andere Tarzan-Knoten auswählen ● Tunnel aufbauen (verteilen der session keys) ● Pakete durch Tunnel routen ● letzter Knoten im Tunnel: NAT ● Pakete an Server routen ● Pakete vom Server durch Tunnel routen ● jeder Knoten des Tunnels: ● entfernt Verschlüsselungsschicht (Paket vom Client) ● fügt Schicht hinzu (Paket in Richtung Client)

12 12 May 2006 - 12 Systems Architecture http://sar.informatik.hu-berlin.de Pakete (1) ● 2 Arten von Nachrichten (beide als UDP): ● Datenpakete ● Kontrollpakete ● flow tag: eindeutige Identifizierung einer Tunnelverbindung ● symmetrische Verschlüsselung ● verschiedene Schlüssel pro Richtung

13 13 May 2006 - 13 Systems Architecture http://sar.informatik.hu-berlin.de Pakete (2) ● Initiator löscht Quelladresse im IP-Paket ● geschachtelte Verschlüsselung, in UDP Paket c i = ENC(encryptionKey h i, {B i+1 }) a i = MAC(integrityKey h i, {sequenceNr,c i }) B i = {sequenceNr, c i, a i } ● Initiator sendet B 1 an h 1 ● h i :flow tag -> key wählen, Integritätstest ● h i :tag in B i+1 setzen, als UDP an h i+1 leiten

14 14 May 2006 - 14 Systems Architecture http://sar.informatik.hu-berlin.de Tunnelaufbau (1) ● Client wählt Knoten aus dem Netzwerk ● Initiator baut Tunnel schrittweise auf ● generiert und verteilt symmetrische Schlüssel ● “establish request” an gewählte Knoten: ● verschlüsselt mit public key des jeweiligen Knoten h i ● forward session key (für Pakete von h i-1 ) verschlüsselt: ● forward integrity key ● entsprechende Schlüssel für Pakete von h i+1 ● Adressen von h i-1 und h i+1 ● flow identifiers ● jedes h i : end-to-end check (Test der Korrektheit)

15 15 May 2006 - 15 Systems Architecture http://sar.informatik.hu-berlin.de Tunnelaufbau (2) ● Verbindungsdaten an h i sind normale Pakete ● Empfänger weiß nicht, von wem das Paket kommt ● enthalten Sitzungsschlüssel, verschlüsselt mit public key von h i

16 16 May 2006 - 16 Systems Architecture http://sar.informatik.hu-berlin.de Tunnelaufbau - Pseudocode

17 17 May 2006 - 17 Systems Architecture http://sar.informatik.hu-berlin.de IP-Paket Forwarding ● pseudonymous Network Address Translator (PNAT) ● weist Tarzan-Client private IP (192.168.x.x) zu ● kann Ports forwarden (Verbindung Tarzan host -> anonymer Server) ● client forwarder ● erhält Pakete vom Netzwerkstack, routet sie über den Tunnel ● ersetzt reale IP-Adresse mit der von PNAT bereitgestellten ● verschleiert Ports ● double-blinded channel ● z.B. zwischen 2 Programmen ● Verbindung einer Anwendungen mit PNAT der anderen

18 18 May 2006 - 18 Systems Architecture http://sar.informatik.hu-berlin.de Verbindung über den Tunnel (1) ● Tunnel ist hergestellt

19 19 May 2006 - 19 Systems Architecture http://sar.informatik.hu-berlin.de Verbindung über den Tunnel (2) ● reale IP des Clients wird ersetzt ● Pakete werden auf festgelegte Länge gebracht ● Verschlüsselung für jeden Knoten des Tunnels (-> UDP)

20 20 May 2006 - 20 Systems Architecture http://sar.informatik.hu-berlin.de Verbindung über den Tunnel (3) ● schrittweiser Abbau der Verschlüsselung ● Weiterleitung an nächsten Hop, im cover traffic

21 21 May 2006 - 21 Systems Architecture http://sar.informatik.hu-berlin.de Verbindung über den Tunnel (4) ● IP des PNAT in IP-Paket eintragen ● nach außen stellt sich PNAT als „Anfrager“ dar

22 22 May 2006 - 22 Systems Architecture http://sar.informatik.hu-berlin.de Verbindung über den Tunnel (5) ● PNAT liest IP des Zieles ● sendet Paket an Ziel über „normales Internet“

23 23 May 2006 - 23 Systems Architecture http://sar.informatik.hu-berlin.de Verbindung über den Tunnel (6) ● Antwort des Servers ● mappen auf pseudo-IP des Clients ● Zurück durch den Tunnel, Verschlüsselung ● Mapping auf reale IP des Clients

24 24 May 2006 - 24 Systems Architecture http://sar.informatik.hu-berlin.de Tunnelabbruch ● Problem:ein Knoten im Tunnel fällt aus -> keine Verbindung durch Tunnel möglich ● Lösung: regelmäßiger ping von Initiator an PNAT -> Antwort von PNAT an Initiator zurück ● Tunnel: {h 1, h 2,...,h l,h pnat }

25 25 May 2006 - 25 Systems Architecture http://sar.informatik.hu-berlin.de Wiederherstellung des Tunnels ● PNAT antwortet nicht auf pings -> Fehler finden! ● ping an alle Knoten im Tunnel ● alle Knoten bis h l antworten ● Fehler liegt bei h pnat ● Initiator wählt neuen h pnat für den Tunnel ● Knoten h 1 bis h i antworten, h i+1 antwortet nicht ● Versuch, Tunnel zum bisherigen h pnat aufzubauen,Verbindungen der Anwendungsschicht werden nicht unterbrochen ● neue Knoten h i+1 bis h l wählen, h pnat bleibt der gleiche ● erfolglose Versuche ab i+1: i um 1 verkleinern

26 26 May 2006 - 26 Systems Architecture http://sar.informatik.hu-berlin.de Netzwerk kennenlernen ● über das Tarzan-Netzwerk lernen ● Initial nur wenige bekannte andere Tarzan-Knoten ● Ziel: alle Ressourcen kennen ● gossip-basiertes Protokoll ● initialization (am Anfang) ● redirection (weitergeben neuer Knoten an Nachbarn) ● maintenance (nur neue Informationen/Updates) ● Tupel {IP-Adresse, Port, hash{public key}} ● Tarzan: validierte und unvalidierte Adressen ● Validierung eines Tupels, sobald Knoten korrekte Antwort auf discovery request sendet

27 27 May 2006 - 27 Systems Architecture http://sar.informatik.hu-berlin.de gossip - Pseudocode

28 28 May 2006 - 28 Systems Architecture http://sar.informatik.hu-berlin.de Mimics (1) ● Gefahr: mögliche Analyse des Datenflusses ● verhindert durch cover traffic (= mimic traffic) ● neuer Tarzan-Knoten tritt Netzwerk bei ● wählt k valide Knoten als Mimic-Partner ● ~k Knoten wählen diesen als Mimic-Partner ● Cover traffic zwischen Mimic-Partnern ● Dummy-Pakete, bidirektional ● verschlüsselt mit auszuhandelndem key ● Datenpakete können eingespeist werden ● werden auch verschlüsselt ● nicht zu unterscheiden von Dummy-Paketen

29 29 May 2006 - 29 Systems Architecture http://sar.informatik.hu-berlin.de Mimics (2) ● k global festgelegt ● Beispiel: ~5 Mimic-Partner pro Knoten

30 30 May 2006 - 30 Systems Architecture http://sar.informatik.hu-berlin.de Mimic-Auswahl ● wenn Wahl zufällig nach IP-Adressen: ● viele feindlicher Knoten möglich ● Angreifer mit vielen IPs, jeweils 1 Tarzan-Client ● Auswahl mit Hilfe von Subnetzen ● drei Runden ● (1):erste 16 Bit -> Hashtabelle ● (2):Auswahl eines /16 Subnetzes aus (1), erste 24 Bit hashen ● (3):Mimic-Partner aus /24 Subnetzes aus (2) wählen ● Hashwert aus IP des suchenden Knoten und Datum ● Für /16:hash(IP-Adresse/16, Datum) ● für i-ten Mimic-Partner: i-malige anwendung der Hashfunktion

31 31 May 2006 - 31 Systems Architecture http://sar.informatik.hu-berlin.de Mimic-Auswahl - Beispiel

32 32 May 2006 - 32 Systems Architecture http://sar.informatik.hu-berlin.de Mimic-Auswahl (3) ● Aufbau der Verbindung ● Mimic request von Knoten A an B ● enthält Tupel {IP-Adresse von A, i}, 1<= i <=k ● falls i>k, lehnt B Verbindung ab ● B muss beim lookup in seiner Hashtabelle seine IP erhalten ● Lookup erfolgreich: A ist Mimic-Partner ● Lookup nicht erfolgreich: ● entweder illegaler Versuch, oder: ● B hat „besser passenden“ Partner C -> sendet Informationen an A ● A versucht, C als Partner zu gewinnen ● C nicht erreichbar: Nachricht darüber an B ● B pingt C an, sollte C nicht antworten, wird A Mimic-Partner

33 33 May 2006 - 33 Systems Architecture http://sar.informatik.hu-berlin.de Cover Traffic (1) ● Knoten will Daten senden/weiterleiten ● Cover Traffic durch Datenpakete ersetzen oder ausbalancieren ● wichtig für Anonymität: ● jeder Knoten des Netzwerks könnte Sender/Empfänger sein ● Datenfluss nicht verfolgbar ● Daten nicht von Cover Traffic zu unterscheiden ● Knoten empfängt Datenpaket ● generiert Cover Traffic als Ersatz für Datenpaket

34 34 May 2006 - 34 Systems Architecture http://sar.informatik.hu-berlin.de Cover Traffic (2) ● cover traffic >= 2*('real' data sent) ● Freedman/Morris: outgoing ’real’ data to a single tunnel <= 1/3*(incoming data + cover traffic) -Annahme: mindestens 1/3 der Mimics sind vertrauenswürdig ● Kosten: jede Menge Overhead..

35 35 May 2006 - 35 Systems Architecture http://sar.informatik.hu-berlin.de Verhinderte Angriffe ● Angriff über gossiping ● alle initial bekannten Knoten bösartig ● Angreifer steuert viele Tarzan-Knoten ● verhindert durch Subnet-Auswahl ● Ignorieren des Mimic-Algorithmus ● Falsche Anfragen werden nicht akzeptiert ● Einzelne feindliche Knoten ● Lebenzeit von Tunneln und Mimic-Partnerschaften relativ kurz ● Traffic Analyse ● verhindert durch cover traffic ● Feindliche Mimics ● müssten mind. 2/3 der Mimics eines Knoten sein,durch hashing unwahrscheinlich

36 36 May 2006 - 36 Systems Architecture http://sar.informatik.hu-berlin.de mögliche Angriffe ● Tunnelrekonstruktion ● Informationen auf Anwendungsebene ● Intersection Attack (passives Mitloggen) ● Angriff über verdächtige Knoten ● Timing- und Trafficanalyse

37 37 May 2006 - 37 Systems Architecture http://sar.informatik.hu-berlin.de Implementierung ● testweise in C++ für Unix (FreeBSD 4.3, Linux) ● "very experimental" ● http://pdos.csail.mit.edu/tarzan/download.html http://pdos.csail.mit.edu/tarzan/download.html ● IP-Forwarder und PNAT brauchen root-Rechte ● Bereitstellung einer API ● SHA-1, Blowfish, DSS, Rabin, SFS-Crypt-Library

38 38 May 2006 - 38 Systems Architecture http://sar.informatik.hu-berlin.de Performance

39 39 May 2006 - 39 Systems Architecture http://sar.informatik.hu-berlin.de Transparenz: Transportschicht

40 40 May 2006 - 40 Systems Architecture http://sar.informatik.hu-berlin.de Transparenz: Anwendungsschicht ● Problem: Pakete beinhalten Absenderinformationen ● Beispiele: SMTP, HTTP ● Abhilfe möglich: ● SMTP: Anonymous Remailer ● HTTP: Webproxy ● einige Protokolle wie FTP und IRC werden nativ unterstützt ● Tarzan eignet sich besonders gut als Basis für Anonymisierungsdienste wie Freenet

41 41 May 2006 - 41 Systems Architecture http://sar.informatik.hu-berlin.de Fazit I: Freedman & Morris ● "a flexible layer for sender, recipient, and relationship anonymity, even when operating in real-time" ● "works with any Internet application" ● "decentralized, highly scalable and easy to manage" ● "lack of network core increases its fault-tolerance to individual relay failure, benefiting both anonymity and availability" ● "Tarzan imposes minimal overhead" ● "we hope to reinforce the rights of freedom of speech and freedom of information as integral parts of everyday life"

42 42 May 2006 - 42 Systems Architecture http://sar.informatik.hu-berlin.de Fazit II: Nikita Borisov ● "The Tarzan requirement of maintenance of cover traffic and gossiping protocol has bandwidth and storage overhead and it makes a dent on system scalability” ● "looked less impressive as the performance figures avoided two important aspects, namely, ● 1) the size of the network and ● 2) the overhead of maintaining the cover traffic ● "They used wishy-washy terms like ’slightly perceivable delays’ instead of providing an exact millisecond figure" ● "Morphmix is more usable" - "better performance"

43 43 May 2006 - 43 Systems Architecture http://sar.informatik.hu-berlin.de Quellenverzeichnis http://www.scs.stanford.edu/mfreed/docs/tarzan-ccs02.pdf http://www.scs.stanford.edu/mfreed/docs/tarzan-ccs02-slides.pdf http://pdos.csail.mit.edu/tarzan/download.html (Implementation)http://pdos.csail.mit.edu/tarzan/download.html http://petblog.nikita.ca/?p=12 (Kritik von Nikita Borisov)http://petblog.nikita.ca/?p=12 http://www.scs.stanford.edu/mfreed/ (persönl. HP von Freedman)http://www.scs.stanford.edu/mfreed/ http://pdos.csail.mit.edu/~rtm/ (persönl. Homepage von Morris)http://pdos.csail.mit.edu/~rtm/ http://www.batsweb.org/Scienza/PagineWeb/Disegni/tarzan.gif Hinweis: sämtliche Quellen vom 09.07.07