JAP inside

1. JAPinside Ziele Annahmen und Design Entscheidungen Architektur Funktionsweise Protokolle

2. Projektübersicht und Ziele • Ziel: • Anonymität für jedermann auch gegen starke Angreifer • Implikationen: • Benutzbarkeit ist wichtigste Vorraussetzung zum Erreichen des Ziels • 1. Ergibt sich unmittelbar aus: „für jedermann“ • 2. Anonymität ist multilaterales Schutzziel; je mehr Nutzer desto anonymer; Netzwerkökonomische Effekte • „Benutzbarkeit“ umfasst dabei mehr als üblicherweise leichte Installation, Konfiguration und Bedienung • wichtig: Dienstgüte; sowohl bzgl. Netzparametern (Durchsatz, Latenzzeit etc.) als auch Sicherheit (Anonymität) Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

3. Grundlegende Entscheidungen • Basis des Anonymitätsdienstes bilden Mix-Kaskaden • statische Kette von Mixen (nach Chaum) • erweitert um symmetrisch verschlüsselte Kanäle (ISDN Mixe) • Entscheidung zu Gunsten von Kaskaden vs. Netz aus Sicherheitsgründen; Mix Netz hat eventuell Vorteile aus Sicht von Skalierbarkeit & Betrieb der Anonymisierungsinfrastruktur • Annahme: Mixe werden von Organisationen professionell betrieben • Anwendungsfeld für prototypische Implementierung: WWW • verspricht große Nutzerzahl (Filesharing wäre sicher spannend, verbietet sich aber aus Ressourcengründen...) • Gewährleistung von Senderanonymität • Implikation: • Anonymisierungsdienst sollte verbindungsorientierten, zuverlässigen Transportdienst bieten (vgl. TCP) • echtzeitfähig (mit geringer Verzögerungszeit) Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

4. Grundlegende Entscheidung • Implikationen für die Mix-Software • drei wichtige Designziele: Performance, Performance, Performance... • Unterschied zur typischen Softwareentwicklung: Wiederverwertbarkeit, Robustheit, leichte Wartung etc. sind untergeordnete Ziele • Benutzbarkeit spielt keine entscheidende Rolle, da von Profis betrieben • Zielsysteme: typische Serverplattformen, jedoch ansonsten möglichst wenig Einschränkungen (POSIX als Richtlinie) • C++ als Programmiersprache; hoher Performance mögliche; objektorientiert; weit verbreitet; Entwicklungsumgebungen vorhanden • auf Grund der Vielzahl möglicher Zielsysteme und entsprechende C++ Compiler wurde auf „moderne“ Features wie Exceptions, RTTI, Templates, Standard C++ Bibliothek etc. verzichtet • benutzte Bibliotheken: • müssen ebenfalls auf allen Zielsystemen verfügbar sein; möglichst bereits Bestandteil einer typischen OS Installation • sollten eine gewissen „de-facto“ Standard darstellen, damit Weiterentwicklung und Portierung gewährleistet ist Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

5. Grundlegende Entscheidungen • Gesamtsystem benötigt Clientkomponente als Schnittstelle zum Anonymisierungsdienst; keine zero-footprint Lösung die Schutz gegen starke Angreifer bietet bekannt • Clientkomponente muß: • auf möglichst vielen Systemen laufen; min. auf allen gängigen Desktop-Systemen: Windows, Linux (Unix), MacOS, OS/2, ... • Benutzbarkeitsanforderungen erfüllen • Entwicklungsressourcen beschränkt • Entwicklung unterschiedlicher Versionen für jedes OS nicht möglich • Wahl fiel auf Java: • ausreichend Performance für Clientkomponente • graphische Benutzungsschnittstelle möglich • Laufzeitumgebung für viele System vorhanden; teilweise vorinstalliert (Windows, MacOSX) • Beschränkung auf Java 1.1, da nur diese Version die gewünschte Verbreitung besitzt • Nachteil: keine „tiefe“ Integration in das jeweilige Zielssystem möglich; vorhandene Features höherer Java Versionen konnten nicht genutzt werden Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

6. Grundlegende Entscheidungen • Clientkomponente arbeitet als Proxy für die zu anonymisierende Anwendung (Browser) • Name der Clientkomponente: JAP • JAP und Mixe kommunizieren mittels verbindungsorientiertem, zuverlässigem Transportdienst (typischerweise TCP/IP) • notwendig für Mix-Protokoll • zusätzliche Komponente: InfoService • verteilte Datenbank • speichert Informationen über vorhandene Mix-Kaskaden • Rückmeldung an die Nutzer zur Ermittlung des erreichten Grad der Anonymität • implementiert in Java; nicht Performance kritisch; leichte Umsetzung • soll keine vertrauenswürdige Stelle sein • Anonymisierungsdienst soll auch ohne InfoService benutzbar sein Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

7. Architektur Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

8. weitere Annahmen/Entscheidungen • (Personal) Firewalls sind übliche Mechanismen zur Netzabsicherung (Windows XP 2) • Zugriff auf Anonymisierungsdienst soll auch aus Firewall gesichertem Netz möglich sein • Benutzer haben teilweise Zugriff auf Firewall Regeln — teilweise nicht (Firma) • Implikationen: • Kommunikation mit Anonymisierungsdienst wird „von innen nach außen“ aufgebaut • es sollten möglichst wenig verschieden Verbindungen notwendig sein • Verwendung von „Firewall (Proxy) freundlichen“ Protokollen • Umsetzung: • Kommunikation mit InfoService erfolgt mittels HTTP (gegebenenfalls über Proxy) • JAP verwendet genau eine TCP/IP Verbindung zur Kommunikation mit dem ersten Mix einer Kaskade • gegebenenfalls unter Verwendung eines Proxy (HTTP/SOCKS) • Annahme: mittlere Mixe sind von außen (direkt) im Allgemeinen nicht zu erreichen Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

9. Mix-Protokoll • basierend auf Chaumschen Mixen & symmetrisch verschlüsselten Kanälen • Einheit für die Verbindung von zwei Kommunikationsendpunkten ist der MixKanal • ein MixKanal bietet einen zuverlässigen, verbindungsorientierten Vollduplex-Transportdienst • der pro MixKanal transportierte Datenstrom wird auf mehrere MixPakete aufgeteilt • alle MixPakete sind gleich groß • Protokollphasen: • Verbindungsaufbau: wird nur vom Sender initiiert durch Versand eines hybrid verschlüsselten Verbindungsaufbaupaketes • Datenübertragung: Sender und Empfänger verschicken symmetrisch verschlüsselte Datenpakete • Verbindungsabbau: Sender oder Empfänger verschicken symmetrisch verschlüsseltes Verbindungsabbaupaket • aus Performance Gründen werden alle MixKanäle über genau eine Verbindung zwischen den Mixen bzw. jeweils genau einer Verbindung zwischen JAP und erstem Mix gemultiplext. (Vermeidung 3-Wege-Handshake; vgl. HTTP/1.1) Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

10. Mix-Protokoll • Adressierung des Kommunikationspartners: • im Mix-Protokoll selbst können nur Klassen von Proxies adressiert werden • keine Einschränkung der Allgemeinheit da Proxy-Protokolle auch für „plain TCP/IP“ Verbindungen existieren (SOCKS) bzw. eigene Proxy-Protokoll entwickelt werden können • Vorteil: Zusatzfunktionalität von unabhängig entwickelten und „ausgereiften“ Proxies können benutzt werden • Beispiel WWW: Cache-Proxy • allgemein: Zugriffskontrolle; QoS Regulierung etc. • Client Implementierung wird vereinfacht, da Umsetzung in das Proxy-Protokoll oft bereits durch die Anwendung erfolgt (Browser) • Kryptographie • jeder Mix besitzt „langlebigen“ (DSA-)Signaturschlüssel (zur Etablierung einer digitalen Identität) • asymmetrisches Schlüsselpaar für Konzelation: 1024 Bit plain RSA • unsicher, aber Untersuchungen über geeignetes Verfahren noch nicht abgeschlossen • symmetrisch: 128-OFB AES • Unterstützung von Replay-Angriffs-Verhinderung Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

11. MixPaket • allgemeiner Aufbau: • ID: • für Zuordnung MixPaket<-> MixKanal (Auswahl des symmetrischen Umkodierungsschlüssels im Mix) • wird zufällig gewählt und ändert sich von Mix zu Mix • werden nicht komplett von JAP vorgegeben, um Kollisionen zu vermeiden • Größe: 4 Byte  ca. 232 gleichzeitige MixKanäle (ausreichend für realistisch große Gruppe von Nutzern) • Steuerinformationen (Flags) • Signalisierung von Protokollzuständen (Verbindungsaufbau, -abbau etc.) • Größe: 2 Bytes • Daten • Größe: • sollte Vielfaches typischer Blockgrößen von symm. Chiffren sein • sollte typischen HTTP-Request (200-700 Bytes) aufnehmen können • sollte kleiner als typische MTU sein (1500 bei Ethernet) => 992 Bytes Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

12. MixPaket Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

13. MixPaket • zusätzliche Informationen im JAP und letzten Mix • Längenangabe (2 Bytes) für die tatsächlichen Nutzdaten pro MixPaket (Rest ist Padding mit Zufall) • Typ (1 Byte) zur Adressierung des Proxy • Payload (989 Bytes) zu übertragende Nutzdaten (eventuell aufgefüllt mit Padding) • zusätzliche Verbindungsverschlüsselung zwischen MixMix bzw. JAPMix • Außenstehende sollen keinen Zugriff auf Kanal-ID und Steuerinformationen haben • verwendet wird AES-128/128 im OFB-128 Modus • aus Performance Gründen werden nur die ersten 16 Bytes (=AES Blocklänge) pro MixPaket verschlüsselt Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

14. Umkodierung • symmetrische Umschlüsselung • umkodiert wird grundsätzlich der gesamte Datenteil (992 Bytes) um mögliche Timing Angriffe zu verhindern • es erfolgt kein „Verschieben“ der Daten • asymmetrische Umschlüsselung (Verbindungsaufbau) • der Aufbau des Verbindungsaufbaupaketes unterscheidet sich geringfügig von den anderen MixPaketen, da Verbindungsaufbaupakete hybrid verschlüsselt sind • zur Umschlüsselung entschlüsselt ein Mix zunächst die ersten 128 Bytes des Datenteils mit seinem geheimen RSA-Schlüssel • die ersten 16 Bytes bilden den symmetrischen Kanal-Schlüssel • mit dem symmetrischen Kanal-Schlüssel werden die restlichen 864 Bytes entschlüsselt • die 16 Schlüssel Bytes werden aus dem MixPaket entfernt; die restlichen Daten werden um diese 16 Bytes verschoben; „am Ende“ des MixPaketes wird mit 16 zufälligen Bytes aufgefüllt • der Mix muß auf diese Weise nicht wissen, an welcher Position er ist Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

15. ID Flags ID‘ Flags Verarbeitung bei symmetrischer Umkodierung 1. MixPaket trifft ein MixPaket MixPaket 2. Entschlüsselung der ersten 16 Bytes mit Inter-Mix-Verbindungsschlüssel 3.Entschlüsselung der Daten mit kID 4.Ändern von ID zu ID‘ 5.Verschlüsselung der ersten 16 Bytes mit Inter-Mix-Verbindungsschlüssel 6.Versenden an den nachfolgenden Mix Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

16. ID Flags kID ID‘ Flags Verarbeitung bei asymmetrischer Umkodierung 1. MixPaket trifft ein MixPaket MixPaket Zufall 2. Entschlüsselung der ersten 16 Bytes mit Inter-Mix-Verbindungsschlüssel 3. Entschlüsselung der ersten 128 Bytes des Datenteils mit Mix-Schlüssel 4.Entschlüsselung der restlichen Daten mit kID 5.Verschieben der Daten „nach links“ & Auffüllen mit Zufallszahlen 6.Erzeugen von ID‘ & Ändern von ID zu ID‘ 7.Verschlüsselung der ersten 16 Bytes mit Inter-Mix-Verbindungsschlüssel 8.Versenden an den nachfolgenden Mix Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

17. Umsortieren: Pool-Mix Bei Eintreffen eines MixPaketes: • Zufällige Auswahl eines MixPaketes (hat Kanal-ID ID) • Suchen nach dem „frühesten“ MixPaket mit Kanal-ID ID im Pool • Ausgabe des MixPaketes • Hinzufügen des empfangenen MixPaketes Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

18. Verhinderung von Replay-Angriffen [work in progress] Allgemein: Kombination von 3 Maßnahmen: • Wechsel des Mix-Schlüssels • Zeitstempel in MixPaketen • Datenbank gemixter Pakete Konkret: • Mix wechselt min. einmal pro Jahr seinen Schlüssel • Verbindungsaufbaupaket enthält Zeitstempel t und ist nur innerhalb eines 10minütigen Zeitintervalls gültig • Zeitintervall wird relativ zum Erzeugungszeitpunkt des Mix-Schlüssels angegeben (16 Bit) • kID=f(t,k‘ID); (Beispiel: kID=t| k‘ID) • während des Zeitintervalls t wird kID in einer Datenbank gespeichert Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

19. Verhinderung von Replay-Angriffen [work in progress] => Replay Verhinderung: • wird ein Verbindungsaufbaupaket unverändert wieder eingespielt, so: • ist entweder der Zeitstempel ungültig => drop • oder kID bereits in der Datenbank => drop • wird ein Verbindungsaufbaupaket verändert wieder eingespielt, so: • wurde t geändert, um das Paket zu einem späteren Zeitpunkt einzuspielen => kID hat sich geändert • wurde k‘IDgeändert, um das Paket im gleichen Zeitintervall einzuspielen => kID hat sich geändert • Unterschiede in kID führen zu vollständig unterschiedlicher symmetrischer Umkodierung => Einspielen symmetrisch umkodierter Pakete bringt nichts, da auf Grund von OFB (synchrone Stromchiffre) völlig unterschiedliche Ausgaben entstehen Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

20. Kommunikation mit dem InfoService • erfolgt mittels HTTP: GET /mixes • Methode und Pfadangabe der URL bestimmen auszuführenden Befehl • Content-Type: text/xml • Übertragen werden XML Strukturen, die weitere Informationen enthalten • signiert mittels XML-Signatur • jeder Mix und jede Kaskade besitzen eindeutigen Bezeichner • jeder Mix sendet Informationen über sich alle 10 Minuten an den InfoService (Name, Betreiber, Standort etc.) • erster Mix einer Kaskade sendet Statusinformationen (Benutzer, gemixte Pakete) jede Minute an InfoService • JAP erfragt Status der aktiven Kaskade jede Minute • JAP kann Liste aktiver Kaskaden und Mixe erfragen Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

21. Kommunikation mit dem InfoService • verteilter InfoService: • aus Gründer der Ausfallsicherheit ist der InfoService als verteilter Dienst realisiert • InfoService-Server arbeiten als Peer-To-Peer Netzwerk zusammen • Nachrichten werden an alle InfoService-Server weitergeleitet • Update der JAP Software: • benutzt wird die Technologie von Java-Webstart (Protokoll zum Starten von Java-Anwendungen aus einem Browser heraus; sieht Möglichkeiten für Softwareupdates vor) • Vorteil: Infrastruktur kann sowohl zum JAP Update als auch für das Starten von JAP mittels Java Webstart verwendet werden Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

22. Kommunikation mit dem InfoService 1. jeder Mix sendet Informationen über sich alle 10 Minuten an den InfoService (Name, Betreiber, Standort etc.) 2. erster Mix einer Kaskade sendet Statusinformationen (Benutzer, gemixte Pakete) jede Minute an InfoService Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

23. Kommunikation mit dem InfoService • momentan definierte Befehle (Anonymisierungsdienst bezogen): • POST /helo • von: Mix • enthält: Informationen über den Mix • POST /cascade • von: ersten Mix einer Kaskade • enthält: allen Informationen über die Kaskade • POST /feedback • von: ersten Mix einer Kaskade • enthält: Informationen über den derzeitigen Status (Verkehr, Nutzer etc.) • GET /cascades Informationen über alle Kaskaden • GET /cascadeinfo/[cascadeid] Informationen über die Kaskade mit der ID cascadeid (es sind die gleichen Informationen wie bei /cascades nur für eine einzelne Kaskade) • GET /mixcascadestatus/[cascadeid] Informationen über den derzeitigen Status der Kaskade mit der ID cascadeid • GET /mixes Informationen über alle Mixe • GET /mixinfo/[mixid] Informationen über den Mix mit der ID mixid • GET /status Informationen über den Status aller Kaskaden zur Ansicht als HTML-Datei Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

24. Kommunikation mit dem InfoService • momentan definierte Befehle (InfoService bezogen): • POST /infoserver • von: InfoService • enthält: Informationen über den InfoService • GET /infoservicesXML-Struktur mit allen InfoServices erhalten, welche der InfoService kennt Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

25. Kommunikation mit dem InfoService • momentan definierte Befehle (JAP Update bezogen): • GET /currentjapversion liefert die Versionsnummer der minimal nötigen JAP-Software • POST /currentjapversion • von: InfoService • enthält: minimal nötigen JAP Version • GET /japRelease.jnlp bzw. /japDevelopment.jnlp liefert die Java-Webstart-Files der aktuellen JAP-Client-Software • HEAD /japRelease.jnlp bzw. /japDevelopment.jnlp schreibt nur einen HTTP-Header für die JNLP-Dateien ohne sie zu übertragen (wird von Java Webstart gebraucht) • POST /japRelease.jnlp bzw. /japDevelopment.jnlp • von: InfoService • enthält: Java-Webstart-Files der aktuellen JAP-Client-Software Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

26. Verbindungsaufbau JAP<->Kaskade • JAP etabliert TCP/IP-Verbindung zum ersten Mix einer Kaskade • Mix sendet signierte Liste mit je einem Eintrag pro Mix der Kaskade an JAP: • XML Struktur • jeder Eintrag der Liste enthält: • öffentlichen RSA Schlüssel des Mixes • ID des Mixes • Signatur geleistet von Mix • zusätzlich noch Protokoll Versionsnummer • JAP sendet symmetrischen Schlüssel für Verbindungsverschlüsselung JAPerster Mix an Mix (verschlüsselt mit öffentlichem Schlüssel des Mix) • zur Verhinderung von DoS: pro IP-Adresse nur 10 Verbindungen • Problem: Nutzer hinter NAT Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

27. Einrichten einer Kaskade • Vorraussetzung: min. 2 Mix-Betreiber, die einen Mix aufgesetzt haben • Reihenfolge der Mixe muß durch die Betreiber gemeinschaftlich festgelegt werden • jeder Mix (außer der letzte) muß wissen, wie er seinen Nachfolger erreichen kann • jeder Mix kennt Signatur-Testschlüssel seiner (maximal zwei) Nachbarn • Initialisierung der Kaskade: • letzter Mix wartet auf Verbindungsaufbau • vorletzter Mix initiiert Verbindung mit letztem Mix • letzter Mix sendet signiert seine ID & öffentlichen Schlüssel an Vorgänger • vorletzter Mix sendet signierten verschlüsselten symmetrischen Verbindungsschlüssel an letzten Mix • zusätzlich: Challenge-Response für Aktualität • vorletzter Mix wartet auf Verbindungsaufbau … • vorletzter Mix sendet seinen und den Schlüssel des letzten Mixes an vorvorletzten und so fort • erster Mix erhält so alle Mix-Schlüssel • bei Übertragungsfehlern innerhalb der Kaskade: Neuinitialisierung Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

28. Starten der Kaskade • Mix wird gestartet • Mix 2 verbindet sich zu Mix 3 (TCP/IP Verbindung) • Mix 3 sendet öffentlichen Schlüssel (signiert) • Mix 2 sendet symmetrischen Verbindungsschlüssel (verschlüsselt und signiert) • Mix 1 verbindet sich zu Mix 2 • Mix 2 sendet seinen öffentlichen Schlüssel (signiert von Mix2) und den von Mix 3 (signiert von Mix 3) • Mix 1 sendet symmetrischen Verbindungsschlüssel (verschlüsselt und signiert) Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

30. Zusammenarbeit im Projekt • cvs • Programmierrichtlinien • JBuilder • C++BuilderX • e-Mail • Videokonferenz Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA