JAP inside Stefan Kpsell z z z Ziele

JAP inside Stefan Köpsell z z z Ziele Annahmen und Design Entscheidungen Architektur Funktionsweise Protokolle 12/5/2020

Projektübersicht und Ziele z Ziel: Ö Anonymität für jedermann auch gegen starke Angreifer z Implikationen: Ö Benutzbarkeitist 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) 2/28

Grundlegende Entscheidungen z 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 z 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) 3/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

Grundlegende Entscheidung z Implikationen für die Mix-Software Ö drei wichtige Designziele: 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 4/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

Grundlegende Entscheidungen z Gesamtsystem benötigt Clientkomponente als Schnittstelle zum Anonymisierungsdienst; keine zero-footprint Lösung die Schutz gegen starke Angreifer bietet bekannt z Clientkomponente muß: Ö auf möglichst vielen Systemen laufen; min. auf allen gängigen Desktop. Systemen: Windows, Linux (Unix), Mac. OS, OS/2, . . . Ö Benutzbarkeitsanforderungen erfüllen z Entwicklungsressourcen beschränkt Ö Entwicklung unterschiedlicher Versionen für jedes OS nicht möglich z Wahl fiel auf Java: Ö ausreichend Performance für Clientkomponente Ö graphische Benutzungsschnittstelle möglich Ö Laufzeitumgebung für viele System vorhanden; teilweise vorinstalliert (Windows, Mac. OSX) Ö 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 5/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

Grundlegende Entscheidungen z Clientkomponente arbeitet als Proxy für die zu anonymisierende Anwendung (Browser) z Name der Clientkomponente: JAP z JAP und Mixe kommunizieren mittels verbindungsorientiertem, zuverlässigem Transportdienst (typischerweise TCP/IP) Ö notwendig für Mix-Protokoll z zusätzliche Komponente: Info. Service Ö 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 Info. Service benutzbar sein 6/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

Architektur 7/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

weitere Annahmen/Entscheidungen z (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 Info. Service 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 8/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

Mix-Protokoll z basierend auf Chaumschen Mixen & symmetrisch verschlüsselten Kanälen Ö Einheit für die Verbindung von zwei Kommunikationsendpunkten ist der Mix. Kanal Ö ein Mix. Kanal bietet einen zuverlässigen, verbindungsorientierten Vollduplex. Transportdienst Ö der pro Mix. Kanal transportierte Datenstrom wird auf mehrere Mix. Pakete aufgeteilt Ö alle Mix. Pakete 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 Mix. Kanä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) 9/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

Mix-Protokoll z 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; Qo. S Regulierung etc. Ö Client Implementierung wird vereinfacht, da Umsetzung in das Proxy. Protokoll oft bereits durch die Anwendung erfolgt (Browser) z 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 10/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

Mix. Paket z allgemeiner Aufbau: Ö ID: ± für Zuordnung Mix. Paket <-> Mix. Kanal (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 Mix. Kanä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 11/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

Mix. Paket 12/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

Mix. Paket z zusätzliche Informationen im JAP und letzten Mix Ö Längenangabe (2 Bytes) für die tatsächlichen Nutzdaten pro Mix. Paket (Rest ist Padding mit Zufall) Ö Typ (1 Byte) zur Adressierung des Proxy Ö Payload (989 Bytes) zu übertragende Nutzdaten (eventuell aufgefüllt mit Padding) z 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 Mix. Paket verschlüsselt 13/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

Umkodierung z 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 z asymmetrische Umschlüsselung (Verbindungsaufbau) Ö der Aufbau des Verbindungsaufbaupaketes unterscheidet sich geringfügig von den anderen Mix. Paketen, 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 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 Mix. Paket entfernt; die restlichen Daten werden um diese 16 Bytes verschoben; „am Ende“ des Mix. Paketes wird mit 16 zufälligen Bytes aufgefüllt ± der Mix muß auf diese Weise nicht wissen, an welcher Position er ist 14/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

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

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

Umsortieren: Pool-Mix Bei Eintreffen eines Mix. Paketes: 1. Zufällige Auswahl eines Mix. Paketes (hat Kanal-ID ID) 2. Suchen nach dem „frühesten“ Mix. Paket mit Kanal-ID ID im Pool 3. Ausgabe des Mix. Paketes 4. Hinzufügen des empfangenen Mix. Paketes 17/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

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

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

Kommunikation mit dem Info. Service z 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 Info. Service (Name, Betreiber, Standort etc. ) Ö erster Mix einer Kaskade sendet Statusinformationen (Benutzer, gemixte Pakete) jede Minute an Info. Service Ö JAP erfragt Status der aktiven Kaskade jede Minute Ö JAP kann Liste aktiver Kaskaden und Mixe erfragen 20/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

Kommunikation mit dem Info. Service z verteilter Info. Service: Ö aus Gründer Ausfallsicherheit ist der Info. Service als verteilter Dienst realisiert Ö Info. Service-Server arbeiten als Peer-To-Peer Netzwerk zusammen Ö Nachrichten werden an alle Info. Service-Server weitergeleitet z 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 21/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

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

Kommunikation mit dem Info. Service z 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. ) 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 Ö GET /cascades Ö Ö Ö 23/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

Kommunikation mit dem Info. Service z momentan definierte Befehle (Info. Service bezogen): Ö POST /infoserver ± von: Info. Service ± enthält: Informationen über den Info. Service /infoservices XML-Struktur mit allen Info. Services erhalten, welche der Info. Service kennt Ö GET 24/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

Kommunikation mit dem Info. Service z momentan definierte Befehle (JAP Update bezogen): GET /currentjapversion liefert die Versionsnummer der minimal nötigen JAP-Software Ö POST /currentjapversion Ö ± von: Info. Service ± enthält: minimal nötigen JAP Version GET /jap. Release. jnlp bzw. /jap. Development. jnlp liefert die Java. Webstart-Files der aktuellen JAP-Client-Software Ö HEAD /jap. Release. jnlp bzw. /jap. Development. jnlp schreibt nur einen HTTP-Header für die JNLP-Dateien ohne sie zu übertragen (wird von Java Webstart gebraucht) Ö POST /jap. Release. jnlp bzw. /jap. Development. jnlp Ö ± von: Info. Service ± enthält: Java-Webstart-Files der aktuellen JAP-Client-Software 25/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

Verbindungsaufbau JAP<->Kaskade z JAP etabliert TCP/IP-Verbindung zum ersten Mix einer Kaskade z 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 z JAP sendet symmetrischen Schlüssel für Verbindungsverschlüsselung JAP�erster Mix an Mix (verschlüsselt mit öffentlichem Schlüssel des Mix) z zur Verhinderung von Do. S: pro IP-Adresse nur 10 Verbindungen Ö Problem: Nutzer hinter NAT 26/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

Einrichten einer Kaskade z 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 z 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 z bei Übertragungsfehlern innerhalb der Kaskade: Neuinitialisierung 27/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

Starten der Kaskade 1. 2. 3. 4. 5. 6. 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 sendet seinen öffentlichen Schlüssel (signiert von Mix 2) und den von Mix 3 (signiert von Mix 3) 7. Mix 1 sendet symmetrischen Verbindungsschlüssel (verschlüsselt und signiert) 28/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A

Zusammenarbeit im Projekt z z z cvs Programmierrichtlinien JBuilder C++Builder. X e-Mail Videokonferenz 30/28 Stefan Köpsell sk 13@inf. tu-dresden. de TU Dresden, Inst. Sy. A