Stefan Köpsell JAP inside Ziele Annahmen und Design Entscheidungen Architektur Funktionsweise...

Stefan Köpsell

JAPinside

Ziele Annahmen und Design Entscheidungen Architektur Funktionsweise Protokolle

Stefan Kö[email protected]

TU Dresden, Inst.SyA2/28

Projektübersicht und Ziele

Ziel:Anonymität für jedermann auch gegen starke Angreifer

Implikationen:Benutzbarkeit ist wichtigste Vorraussetzung zum

Erreichen des Ziels1. 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 Bedienungwichtig: Dienstgüte; sowohl bzgl. Netzparametern

(Durchsatz, Latenzzeit etc.) als auch Sicherheit (Anonymität)



Grundlegende Entscheidungen

Basis des Anonymitätsdienstes bilden Mix-Kaskadenstatische 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: WWWverspricht große Nutzerzahl (Filesharing wäre sicher spannend,

verbietet sich aber aus Ressourcengründen...)Gewährleistung von SenderanonymitätImplikation:

Anonymisierungsdienst sollte verbindungsorientierten, zuverlässigen Transportdienst bieten (vgl. TCP)

echtzeitfähig (mit geringer Verzögerungszeit)



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




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




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: InfoServiceverteilte Datenbankspeichert Informationen über vorhandene Mix-KaskadenRückmeldung an die Nutzer zur Ermittlung des erreichten Grad der

Anonymität implementiert in Java; nicht Performance kritisch; leichte Umsetzungsoll keine vertrauenswürdige Stelle seinAnonymisierungsdienst soll auch ohne InfoService benutzbar sein



Architektur



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



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)



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



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



MixPaket



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 MixMix bzw. JAPMix

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



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



Verarbeitung bei symmetrischer Umkodierung

1. MixPaket trifft ein

MixPaket

2. Entschlüsselung der ersten 16 Bytes mit Inter-Mix-Verbindungsschlüssel

ID Flags

3. Entschlüsselung der Daten mit kID

4. Ändern von ID zu ID‘

ID‘ Flags

5. Verschlüsselung der ersten 16 Bytes mit Inter-Mix-Verbindungsschlüssel

6. Versenden an den nachfolgenden Mix

MixPaket



Verarbeitung bei asymmetrischer Umkodierung

1. MixPaket trifft ein

MixPaket

2. Entschlüsselung der ersten 16 Bytes mit Inter-Mix-Verbindungsschlüssel

ID Flags

4. Entschlüsselung der restlichen Daten mit kID

kID

6. Erzeugen von ID‘ & Ändern von ID zu ID‘7. Verschlüsselung der ersten 16 Bytes mit Inter-Mix-Verbindungsschlüssel8. Versenden an den nachfolgenden Mix

3. Entschlüsselung der ersten 128 Bytes des Datenteils mit Mix-Schlüssel

5. Verschieben der Daten „nach links“ & Auffüllen mit Zufallszahlen

Zufall

ID‘ Flags

MixPaket



Umsortieren: Pool-Mix

Bei Eintreffen eines MixPaketes:1. Zufällige Auswahl eines MixPaketes (hat Kanal-ID ID)2. Suchen nach dem „frühesten“ MixPaket mit Kanal-ID ID im Pool3. Ausgabe des MixPaketes4. Hinzufügen des empfangenen MixPaketes



Verhinderung von Replay-Angriffen [work in progress]

Allgemein: Kombination von 3 Maßnahmen:1. Wechsel des Mix-Schlüssels2. Zeitstempel in MixPaketen3. 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

ti, t j .ti t j f (ti,) f (t j ,)



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‘ID geä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



Kommunikation mit dem InfoService

erfolgt mittels HTTP: GET /mixesMethode und Pfadangabe der URL bestimmen auszuführenden

BefehlContent-Type: text/xml

Übertragen werden XML Strukturen, die weitere Informationen enthalten

signiert mittels XML-Signaturjeder 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




verteilter InfoService:aus Gründer der Ausfallsicherheit ist der InfoService als verteilter

Dienst realisiert InfoService-Server arbeiten als Peer-To-Peer Netzwerk zusammenNachrichten 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




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




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




momentan definierte Befehle (InfoService bezogen):POST /infoserver

von: InfoServiceenthält: Informationen über den InfoService

GET /infoservices XML-Struktur mit allen InfoServices erhalten, welche der InfoService kennt




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



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 Strukturjeder Eintrag der Liste enthält:

öffentlichen RSA Schlüssel des MixesID des MixesSignatur geleistet von Mix

zusätzlich noch Protokoll Versionsnummer JAP sendet symmetrischen Schlüssel für

Verbindungsverschlüsselung JAPerster Mix an Mix (verschlüsselt mit öffentlichem Schlüssel des Mix)

zur Verhinderung von DoS: pro IP-Adresse nur 10 VerbindungenProblem: Nutzer hinter NAT



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



Starten der Kaskade

1. Mix wird gestartet2. Mix 2 verbindet sich zu Mix 3 (TCP/IP Verbindung)3. Mix 3 sendet öffentlichen Schlüssel (signiert)4. Mix 2 sendet symmetrischen Verbindungsschlüssel (verschlüsselt und signiert)5. Mix 1 verbindet sich zu Mix 26. Mix 2 sendet seinen öffentlichen Schlüssel (signiert von Mix2) und den von Mix 3

(signiert von Mix 3)7. Mix 1 sendet symmetrischen Verbindungsschlüssel (verschlüsselt und signiert)



Zusammenarbeit im Projekt

cvs Programmierrichtlinien JBuilder C++BuilderX e-Mail Videokonferenz

Stefan Köpsell JAP inside Ziele Annahmen und Design Entscheidungen Architektur Funktionsweise...

Documents

Transcript of Stefan Köpsell JAP inside Ziele Annahmen und Design Entscheidungen Architektur Funktionsweise...