View
106
Download
3
Category
Preview:
Citation preview
Stefan Köpsell
JAPinside
Ziele Annahmen und Design Entscheidungen Architektur Funktionsweise Protokolle
Stefan Köpsellsk13@inf.tu-dresden.de
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)
Stefan Köpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA3/28
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)
Stefan Köpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA4/28
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öpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA5/28
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öpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA6/28
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: 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
Stefan Köpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA7/28
Architektur
Stefan Köpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA8/28
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öpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA9/28
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öpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA10/28
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öpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA11/28
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öpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA12/28
MixPaket
Stefan Köpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA13/28
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
Stefan Köpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA14/28
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öpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA15/28
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
Stefan Köpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA16/28
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
Stefan Köpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA17/28
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
Stefan Köpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA18/28
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 ,)
Stefan Köpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA19/28
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
Stefan Köpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA20/28
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
Stefan Köpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA21/28
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 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
Stefan Köpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA22/28
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öpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA23/28
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öpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA24/28
Kommunikation mit dem InfoService
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
Stefan Köpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA25/28
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öpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA26/28
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
Stefan Köpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA27/28
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öpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA28/28
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)
Stefan Köpsellsk13@inf.tu-dresden.de
TU Dresden, Inst.SyA30/28
Zusammenarbeit im Projekt
cvs Programmierrichtlinien JBuilder C++BuilderX e-Mail Videokonferenz
Recommended