Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Stefan Köpsell JAP inside Ziele Annahmen und Design Entscheidungen Architektur Funktionsweise Protokolle."—  Präsentation transkript:

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

2 2/28 Stefan Köpsell TU Dresden, Inst.SyA 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)

3 3/28 Stefan Köpsell 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)

4 4/28 Stefan Köpsell 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

5 5/28 Stefan Köpsell 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

6 6/28 Stefan Köpsell 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

7 7/28 Stefan Köpsell TU Dresden, Inst.SyA Architektur

8 8/28 Stefan Köpsell 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

9 9/28 Stefan Köpsell 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)

10 10/28 Stefan Köpsell 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

11 11/28 Stefan Köpsell 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 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 ( Bytes) aufnehmen können –sollte kleiner als typische MTU sein (1500 bei Ethernet) => 992 Bytes

12 12/28 Stefan Köpsell TU Dresden, Inst.SyA MixPaket

13 13/28 Stefan Köpsell 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

14 14/28 Stefan Köpsell 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

15 15/28 Stefan Köpsell TU Dresden, Inst.SyA Verarbeitung bei symmetrischer Umkodierung 1. MixPaket trifft ein MixPaket 2. Entschlüsselung der ersten 16 Bytes mit Inter-Mix-Verbindungsschlüssel IDFlags 3. Entschlüsselung der Daten mit k ID 4. Ändern von ID zu ID IDFlags 5. Verschlüsselung der ersten 16 Bytes mit Inter-Mix-Verbindungsschlüssel 6. Versenden an den nachfolgenden Mix MixPaket

16 16/28 Stefan Köpsell TU Dresden, Inst.SyA Verarbeitung bei asymmetrischer Umkodierung 1. MixPaket trifft ein MixPaket 2. Entschlüsselung der ersten 16 Bytes mit Inter-Mix-Verbindungsschlüssel IDFlags 4. Entschlüsselung der restlichen Daten mit k ID k ID 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 3. Entschlüsselung der ersten 128 Bytes des Datenteils mit Mix-Schlüssel 5. Verschieben der Daten nach links & Auffüllen mit Zufallszahlen Zufall IDFlags MixPaket

17 17/28 Stefan Köpsell TU Dresden, Inst.SyA 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 Pool 3. Ausgabe des MixPaketes 4. Hinzufügen des empfangenen MixPaketes

18 18/28 Stefan Köpsell TU Dresden, Inst.SyA Verhinderung von Replay-Angriffen [work in progress] Allgemein: Kombination von 3 Maßnahmen: 1. Wechsel des Mix-Schlüssels 2. Zeitstempel in MixPaketen 3. 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) k ID =f(t,k ID ); (Beispiel: k ID =t| k ID ) während des Zeitintervalls t wird k ID in einer Datenbank gespeichert

19 19/28 Stefan Köpsell 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 k ID 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 => k ID hat sich geändert wurde k ID geändert, um das Paket im gleichen Zeitintervall einzuspielen => k ID hat sich geändert Unterschiede in k ID 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

20 20/28 Stefan Köpsell 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

21 21/28 Stefan Köpsell 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

22 22/28 Stefan Köpsell 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

23 23/28 Stefan Köpsell 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 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

24 24/28 Stefan Köpsell 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

25 25/28 Stefan Köpsell 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 von: InfoService enthält: Java-Webstart-Files der aktuellen JAP-Client-Software

26 26/28 Stefan Köpsell 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

27 27/28 Stefan Köpsell 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

28 28/28 Stefan Köpsell TU Dresden, Inst.SyA Starten der Kaskade 1.Mix wird gestartet 2.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 2 6.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)

29

30 30/28 Stefan Köpsell TU Dresden, Inst.SyA Zusammenarbeit im Projekt cvs Programmierrichtlinien JBuilder C++BuilderX Videokonferenz


Herunterladen ppt "Stefan Köpsell JAP inside Ziele Annahmen und Design Entscheidungen Architektur Funktionsweise Protokolle."

Ähnliche Präsentationen


Google-Anzeigen