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

2 May Systems Architecture Einführung ● Peer-to-peer Anonymisierung auf IP-Ebene ● Tarzan: Paket "hangelt sich" von Knoten zu Knoten

3 May Systems Architecture Michael J. Freedman & Robert Morris Freedman (NYU, Stanford) & Morris (MIT)

4 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture Welche Möglichkeiten existieren bisher? ● anonymizer.com ● Onion Routing (TOR) ● Anonymous R er ●...

7 May Systems Architecture Probleme und Gefahren ● Umgehen des Proxy ● Einbruch auf den Proxy ● DOS-Attacke ➔ Abhängigkeit von einem oder wenigen zentralen Instanzen

8 May Systems Architecture Was gilt als bösartig? ● Pakete verändern ● unterschlagen ● speichern ● Analyse des Netzwerkverkehrs ● Rückgabe gefälschter Information ● jegliche sonstige Abweichung vom Protokollstandard

9 May Systems Architecture Architektur und Design ● Überblick ● Pakete ● Tunnelaufbau ● Verbindung über den Tunnel ● Tunnelabbruch und Wiederherstellung ● Netzwerk kennenlernen ● Mimics ● Cover Traffic

10 May Systems Architecture Ü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 May Systems Architecture Ü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 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture Tunnelaufbau - Pseudocode

17 May Systems Architecture IP-Paket Forwarding ● pseudonymous Network Address Translator (PNAT) ● weist Tarzan-Client private IP ( 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 May Systems Architecture Verbindung über den Tunnel (1) ● Tunnel ist hergestellt

19 May Systems Architecture 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 May Systems Architecture Verbindung über den Tunnel (3) ● schrittweiser Abbau der Verschlüsselung ● Weiterleitung an nächsten Hop, im cover traffic

21 May Systems Architecture Verbindung über den Tunnel (4) ● IP des PNAT in IP-Paket eintragen ● nach außen stellt sich PNAT als „Anfrager“ dar

22 May Systems Architecture Verbindung über den Tunnel (5) ● PNAT liest IP des Zieles ● sendet Paket an Ziel über „normales Internet“

23 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture gossip - Pseudocode

28 May Systems Architecture 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 May Systems Architecture Mimics (2) ● k global festgelegt ● Beispiel: ~5 Mimic-Partner pro Knoten

30 May Systems Architecture 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 May Systems Architecture Mimic-Auswahl - Beispiel

32 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture mögliche Angriffe ● Tunnelrekonstruktion ● Informationen auf Anwendungsebene ● Intersection Attack (passives Mitloggen) ● Angriff über verdächtige Knoten ● Timing- und Trafficanalyse

37 May Systems Architecture Implementierung ● testweise in C++ für Unix (FreeBSD 4.3, Linux) ● "very experimental" ● ● IP-Forwarder und PNAT brauchen root-Rechte ● Bereitstellung einer API ● SHA-1, Blowfish, DSS, Rabin, SFS-Crypt-Library

38 May Systems Architecture Performance

39 May Systems Architecture Transparenz: Transportschicht

40 May Systems Architecture Transparenz: Anwendungsschicht ● Problem: Pakete beinhalten Absenderinformationen ● Beispiele: SMTP, HTTP ● Abhilfe möglich: ● SMTP: Anonymous R er ● 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 May Systems Architecture 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 May Systems Architecture 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 May Systems Architecture Quellenverzeichnis (Implementation) (Kritik von Nikita Borisov) (persönl. HP von Freedman) (persönl. Homepage von Morris) Hinweis: sämtliche Quellen vom