JAP inside Ziele Annahmen und Design Entscheidungen Architektur Funktionsweise Protokolle

Projektübersicht und Ziele 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

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

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

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

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

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

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

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

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

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

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

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

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

Verarbeitung bei symmetrischer Umkodierung MixPaket ID‘ Flags ID Flags MixPaket 1. MixPaket trifft ein 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

Verarbeitung bei asymmetrischer Umkodierung ID‘ Flags MixPaket MixPaket ID Flags kID Zufall 1. MixPaket trifft ein 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

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

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

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 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‘ID geändert, um das Paket im gleichen Zeitintervall einzuspielen 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

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

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

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

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 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

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

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 enthält: Java-Webstart-Files der aktuellen JAP-Client-Software Stefan Köpsell sk13@inf.tu-dresden.de TU Dresden, Inst.SyA

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

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

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

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