> Datenschutzfreundliche Techniken im Internet Hannes Federrath

Transkript

1 GET >please type in your name >set cookie > Datenschutzfreundliche Techniken im Internet Hannes Federrath berblick Ð Beobachtbarkeit von Benutzern in Kommunikationsnetzen Datenvermeidung Ð Broadcast Ð Mixe Ð DC-Netz Ð PseudonymitŠt Anwendungen Ð Anonymes Surfen Ð E-Commerce

2 > Anonymity im Internet ist eine Illusion Electronic Mail: Log-Dateien zeigen Kommunikationsbeziehungen >tail syslog Oct 15 16:32:06 size=1150 Oct 15 16:32:06 World Wide Web: Log-Dateien zeigen Interessensdaten wwwtcs.inf.tu-dresden.de>tail access_log amadeus.inf.tu-dresden.de - - [15/Oct/1997:11:50:01] "GET /lvbeschr/winter/technds.html HTTP/1.0" - " "Mozilla/3.01 (X11; I; SunOS sun4u)" Finger: Die Ermittlung eines Rechnerbenutzers ist kein Problem ithif19 logs 17 [amadeus.inf.tu-dresden.de] Login Name TTY Idle When feder Hannes Federrath console Wed 11:56

3 > Beobachtbarkeit von Benutzern in Vermittlungsnetzen Radio TV Video phone Netzabschlu Telephone Internet Abhšrer mšgliche Angreifer Vermittlungsstelle Betreiber Hersteller (Troj. Pferd) Angestellte

4 > Beobachtbarkeit von Benutzern in Vermittlungsnetzen Radio TV Gegenma nahme VerschlŸsselung VerbindungsverschlŸsselung Video phone Netzabschlu Telephone Internet Abhšrer mšgliche Angreifer Vermittlungsstelle Betreiber Hersteller (Troj. Pferd) Angestellte

5 > Beobachtbarkeit von Benutzern in Vermittlungsnetzen Gegenma nahme VerschlŸsselung VerbindungsverschlŸsselung Ende-zu-Ende-VerschlŸsselung der Inhalte Abhšrer mšgliche Angreifer Vermittlungsstelle Betreiber Hersteller (Troj. Pferd) Angestellte Problem Verkehrsdaten: Problem Interessensdaten: Wer mit wem, wann, wie lange, wo, wieviel Information? Wer interessiert sich fÿr was? Verkehrsdaten všllig vermeiden oder so ÇschŸtzenÈ, da sie nicht erfa t werden kšnnen

6 > Datenvermeidung z Juristische Sicht Ö Teledienstedatenschutzgesetz (TDDSG) ± 3(4): Die Gestaltung und Auswahl technischer Einrichtungen fÿr Teledienste hat sich an dem Ziel auszurichten, keine oder so wenige personenbezogene Daten wie mšglich zu erheben, zu verarbeiten und zu nutzen. ± 4(1): Der Diensteanbieter hat dem Nutzer die Inanspruchnahme von Telediensten und ihre Bezahlung anonym oder unter Pseudonym zu ermšglichen, soweit dies technisch mšglich und zumutbar ist. Der Nutzer ist Ÿber diese Mšglichkeiten zu informieren. z Technischer Datenschutz Ö Systeme so konstruieren, da unnštige Daten vermieden und nicht miteinander verkettet werden kšnnen. ± Adressen: Sender, EmpfŠnger, Kommunikationsbeziehung ±Zeitliche Korrelationen: Zeitpunkte, Dauer ± bertragenes Datenvolumen und inhaltliche Korrelationen ±Orte: Aufenthaltsorte, Bewegungsspuren

7 >Schutzziele Vertraulichkeit; hier: Vertraulichkeit der Verkehrsdaten z Unbeobachtbarkeit Ö Schutz von Sender und/oder EmpfŠnger gegenÿber allen Unbeteiligten (inkl. Netzbetreiber) ± Niemand kann Kommunikationsbeziehungen verfolgen. ± Unbeobachtbares Senden und/oder Empfangen von Nachrichten z AnonymitŠt Ö Schutz der IdentitŠt zusštzlich auch gegenÿber dem Kommunikationspartner ± AnonymitŠt als Sender von Nachrichten ± AnonymitŠt als EmpfŠnger von Nachrichten z Unverkettbarkeit Ö Ereignisse werden vom Angreifer bzgl. des Senders und/oder EmpfŠngers als unabhšngig erkannt

8 > AnonymitŠtsgruppe z Ein einzelnes Ereignis, das durch eine einzelne Person hervorgerufen wurde, kann nicht anonym oder unbeobachtbar sein. z Wir benštigen eine Gruppe von Personen, die sich alle gleich verhalten: AnonymitŠtsgruppe Ö Jedes Mitglied der AnonymitŠtsgruppe ist mit der gleichen Wahrscheinlichkeit der Urheber eines Ereignisses. Ö Eine šffentlich bekannte Eigenschaft, die alle Mitglieder der AnonymitŠtsgruppe erfÿllen, kann nicht anonymisiert werden. Nachricht Zugriff AnonymitŠtsgruppe Ereignisse

9 > Verfahren zur unbeobachtbaren Kommunikation z Wer ist zu schÿtzen? Ö Schutz des Senders Ö Schutz des EmpfŠngers Ö Schutz der Kommunikationsbeziehung z Grundkonzepte: Ö Verteilung mit impliziter Adressierung Ö Dummy traffic Ö Proxies Ö DC-Netz Ö Blind-Message-Service Ö Mix-Netz Ö Steganographie AnonymitŠtsgruppe Nachricht Zugriff Ereignisse

10 > GrunsŠtzliche Techniken (1) z Verteilung (Broadcast) + implizite Adressierung Ö Schutz des EmpfŠngers; alle erhalten alles Ö lokale Auswahl z Dummy Traffic: Senden bedeutungsloser Nachrichten Ö Schutz des Senders z Proxies zwischenschalten Ö Server erfšhrt nichts Ÿber Client, Proxy kann mitlesen FROM mypc GET Server.com/page.html FROM Proxy GET Server.com/page.html Browser Proxy Server Angriffsbereich

11 > Schutz des EmpfŠngers: Verteilung (Broadcast) z Adressierung Ö explizite Adressen: Routing Ö implizite Adressen: Merkmal fÿr Station des Adressaten ±verdeckt: Konzelationssystem ± offen: Bsp. Zufallszahlengenerator Adre verwaltung šffentliche Adresse private Adresse implizite verdeckt sehr aufwendig, fÿr aufwendig Adres- Kontaktaufnahme nštig sierung offen abzuraten nach Kontaktaufnahme stšndig wechseln

12 > GrundsŠtzliche Techniken (2) z DC-Netz: kombiniert u.a. Broadcast, Kryptographie und Dummy Traffic Ö Schutz des Senders z Blind-Message-Service: Unbeobachtbare Abfrage aus von unabhšngigen Betreibern replizierten Datenbanken Ö Schutz des Clients z MIX-Netz: kombiniert u.a. hintereinander geschaltete Proxies von unabhšngigen Betreibern, Kryptographie und Dummy Traffic Ö Schutz der Kommunikationsbeziehung Ö Effizient in Vermittlungsnetzen z Steganographie Ö Verbergen einer Nachricht in einer anderen

13 > Angreifermodell z Angreifer kann: Ö alle Kommunikationsleitungen passiv Ÿberwachen (Verkehrsanalysen durchfÿhren), Ö ggf. aktiv eigene Nachrichten beisteuern, Ö ggf. fremde Nachrichten blockieren/verzšgern, Ö ggf. selbst eine ÈUnbeobachtbarkeitsstationÇ sein Ö EmpfŠnger oder Sender sein z Angreifer kann nicht: Ö Kryptosysteme brechen, Ö in den persšnlichen Rechner eindringen, Ö ist komplexitštstheoretisch beschršnkt, d.h. hat begrenzte Zeit und Rechenleistung fÿr seine Angriffe zur VerfŸgung Ein sehr starkes Angreifermodell schÿtzt vor dem UnterschŠtzen des realen Angreifers

14 > DC-Netz Chaum, 1988 A B C Broadcastnetz SchlŸsselgraph A C B Echte Nachricht von A SchlŸssel mit B SchlŸssel mit C Summe A sendet Leere Nachricht von B SchlŸssel mit A SchlŸssel mit C Summe B sendet Leere Nachricht von C SchlŸssel mit A SchlŸssel mit B Summe C sendet Summe = Echte Nachricht von A

15 > DC-Netz z Perfekte Unbeobachtbarkeit des Sendens z Erfordert Synchronisierung der Teilnehmer: Runden z Zu jedem Zeitpunkt kann immer nur ein Teilnehmer senden Ö Kollisionserkennung und -auflšsung nštig z Bei Punkt-zu-Punkt-Kommunikation Ö implizite Adressierung und VerschlŸsselung der Nachricht z Sicherheitseigenschaft Ö Jede Nachricht ist innerhalb der Teilnehmer unbeobachtbar, die durch einen zusammenhšngenden SchlŸsselgraph gebildet werden. Ö Beispiel: SchlŸsselgraph A C Wenn SchlŸssel AÐC kompromittiert ist, kann der Angreifer feststellen, ob Nachricht aus Gruppe {A,B} oder {C,D} stammt. B kann nicht anonym vor A sein, weil B nicht durch einen weiteren, A unbekannten SchlŸssel im Graph verbunden ist. B D

16 > Blind-Message-Service: Anfrage Cooper, Birman, 1995 Client interessiert sich fÿr D[2]: Index = 1234 c S1 (1011) S1 D[1]: D[2]: D[3]: D[4]: Setze Vektor = 0100 WŠhle zufšllig request(s1) = 1011 WŠhle zufšllig request(s2) = 0110 Berechne request(s3) = 1001 c S2 (0110) c S3 (1001) S2 D[1]: D[2]: D[3]: D[4]: S3 D[1]: D[2]: D[3]: D[4]:

17 > Blind-Message-Service: Antwort Cooper, Birman, 1995 Client interessiert sich fÿr D[2]: Index = 1234 Setze Vektor = 0100 WŠhle zufšllig request(s1) = 1011 WŠhle zufšllig request(s2) = 0110 Berechne request(s3) = 1001 Antworten von S1: S2: S3: Summe entspricht D[2]: VerbindungsverschlŸsselung zwischen Servern und Client unbedingt notwendig S1 S2 S3 D[1]: D[2]: D[3]: D[4]: Summe D[1]: D[2]: D[3]: D[4]: Summe D[1]: D[2]: D[3]: D[4]: Summe

18 z Grundidee: Ö Nachrichten in einem ÈSchubÇ ± sammeln, Wiederholungen ignorieren, umkodieren, umsortieren, gemeinsam ausgeben. Ö Alle Nachrichten haben die gleiche LŠnge. Ö Mehr als einen Mix verwenden. Ö Wenigstens ein Mix darf nicht angreifen. z Schutzziel: Ö Unverkettbarkeit von Sender und EmpfŠnger Ö Schutz der Kommunikationsbeziehung Ö Zuordnung zwischen E- und A-Nachrichten wird verborgen Mix-Netz Chaum, 1981 MIX 1 MIX 2

19 > Blockschaltbild eines Mix N = {N 1, N 2,..., N m } N N (i=1...m) Eingabenachrichten Wiederholung ignorieren alle Eingabenachrichten speichern, die gleich umkodiert werden Umkodieren Eingabenachrichten puffern? GenŸgend viele Nachrichten von genÿgend vielen Absendern? Umsortieren Ausgabenachrichten c(n i, z i ) isreplay(c(n i, z i )) d(c(n i, z i )) sort(n) N i

20 Kryptographische Operationen eines Mix z Verwendet asymmetrisches Konzelationssystem c i (...) VerschlŸsselungsfunktion fÿr Mix i ± Jeder kann den šffentlichen SchlŸssel c i verwenden d i (...) private EntschlŸsselung von Mix i ± Nur Mix i kann entschlÿsseln A i r i M Adresse von Mix i Zufallszahl (verbleibt im Mix, wird ÈweggeworfenÇ) (verschlÿsselte) Nachricht fÿr EmpfŠnger (inkl. seiner Adresse) A 1, c 1 (A 2, c 2 (M, r 2 ), r 1 ) d 2 (c 2 (M, r 2 )) MIX 1 MIX 2 M d 1 (c 1 (...)) A 2, c 2 (M, r 2 )

21 > Mixe: Warum Ÿberhaupt umkodieren? Nutzer 1 Nutzer 2. Nutzer x. Proxy GET page.html INTRANET INTERNET z Beobachtung und Verkettung ist mšglich Ö zeitliche Verkettung Ö Verkettung Ÿber Inhalte (Aussehen, LŠnge) VerschlŸsselung zwischen Browser und Proxy verhindert Korrelation Ÿber ÈAussehenÇ, aber nicht Ÿber NachrichtenlŠnge und Zeit und hilft nichts gegen den Proxy.

22 > Mixe: Warum die Zufallszahlen? z Wenn keine Zufallszahlen r verwendet werden: Ö Jeder kann die Ausgabenachrichten probeweise verschlÿsseln, weil c(...) šffentlich ist. Ö Vergleich mit allen eingehenden Nachrichten fÿhrt zur Verkettung Ö Es wird ein indeterministisches Kryptosystem benštigt c(m ) MIX M =? c(m)

23 >> Mixe: Warum die Zufallszahlen? z Wenn keine Zufallszahlen r verwendet werden: Ö Jeder kann die Ausgabenachrichten probeweise verschlÿsseln, weil c(...) šffentlich ist. Ö Vergleich mit allen eingehenden Nachrichten fÿhrt zur Verkettung Ö Es wird ein indeterministisches Kryptosystem benštigt r verbleibt im Mix c(m, r ) MIX M =? c(m)

24 > Mixe: Warum mehr als ein Mix? z Schutzziel: Auch Mix soll nicht beobachten kšnnen Ö Ein einzelner Mix kennt jedoch E-A-Zuordnung z Verwende mindestens zwei Mixe Ö erster Mix kennt Sender Ö letzter Mix kennt EmpfŠnger z Allgemein: Ö Verwende so viele Mixe, da sich in der Mix-Kette wenigstens ein Dir vertrauenswÿrdiger Mix befindet z Praxis: Ö Je mehr Mixe verwendet werden, umso hšufiger mu umkodiert werden und es steigt die Verzšgerungszeit. Ö Es genÿgt, wenn ein einziger Mix tatsšchlich vertrauenswÿrdig ist. Ö Lieber sorgfšltig wenige Mixe auswšhlen. Ö Derzeit verwendet man wenigstens drei, besser fÿnf Mixe, aber das ist rein subjektiv.

25 > Mixe: Warum ÈWiederholungen ignorierenç? z Wehrt Replay-Angriff ab: Ö Angreifer speichert E-A-Zuordnungen eines Schubs, in dem er eine Nachricht enttarnen mšchte. Ö Sendet in spšterem Schub die Nachricht erneut an den Mix. ± Folge ohne ÈWiederholungen ignorierenç: Ð Mix entschlÿsselt Nachricht, wirft Zufallszahl weg und gibt Nachricht in gleicher Kodierung wie beim 1. Mal aus Ð Vergleich mit allen A-Nachrichten des ersten Schubs ermšglicht E-A-Verkettung fÿr betreffende Nachricht z Abwehr: Ö Mix prÿft, ob eine E-Nachricht bereits gemixt wurde Ö erfordert Speichern aller E-Nachrichten, solange Mix sein SchlŸsselpaar nicht wechselt

26 > Mixe: Warum ÈWiederholungen ignorierenç? z Optimierungen Ö Optimierungsziel: Speicherplatz sparen, Suchzeiten verkÿrzen z Optimierung 1: Speichere nur Hashwert oder zufšlligen Teil (z.b. Zufallszahl r) der E-Nachricht Ö Nachteil: Mit geringer Wahrscheinlichkeit wird eine ÈfrischeÇ Nachricht als bereits gemixt erkannt, da es Kollisionen geben kann. Ö Nachteil: Jede E-Nachricht mu bei Speicherung von r zunšchst entschlÿsselt werden z Optimierung 2: In jede Nachricht wird eine Verfallszeit hineinkodiert Ö Solange Verfallszeit nicht Ÿberschritten ist, wird wie Ÿblich verfahren Ö Bei berschreitung der Verfallszeit einer E-Nachricht wird diese sofort ignoriert Ö Datenbank wird von Zeit zu Zeit ÈaufgerŠumtÇ Ö Nachteil: Jede E-Nachricht mu zunšchst entschlÿsselt werden

27 > Warum nicht einfach VerbindungsverschlŸsselung? Angreifer vertrauenswÿrdig Angreifer Server S User U A B C page.html page.html page.html k UA (page.html) k AB (page.html) k BC (page.html) k CS (page.html) VerbindungsverschlŸsselung zwischen den Mixen hilft gegen Au enstehende, aber nicht gegen Betreiber der Mixe.

28 > Mixe: Warum asymmetrische Kryptographie? z Mixe lassen sich nur mit asymmetrischem Konzelationssystem realisieren. Ö Ausnahme: Zwischen Sender und erstem Mix genÿgt symmetrische VerschlŸsselung. z Bei symmetrisch verschlÿsselter Nachricht an mittleren Mix: Ö Ein mittlerer Mix darf nicht erfahren, von welchem Sender eine Nachricht stammt. Symmetrische SchlŸssel werden jedoch paarweise (BenutzerÐMix) ausgetauscht. Wenn der Mix entschlÿsseln kšnnen soll, mu er jedoch den passenden SchlŸssel kennen. Also kennt er den Absender. z Asymmetrisches Konzelationssystem: Ö Benštigte n:1-eigenschaft: Jeder kennt den SchlŸssel und kann eine Nachricht fÿr Mix verschlÿsseln.

29 > Warum sammeln und umsortieren? z Reihenfolge zwischen E- und A-Nachrichten mu unabhšngig sein z 3 Speicher- und Ausgabestrategien Ö Strategie 1: Schub (Chaum, 1981) ± Ein Mix bearbeitet eine stets konstante Zahl von n gÿltigen Eingabenachrichten, d.h. ebenfalls n Nachrichten verlassen den Mix. ± AnonymitŠtsgruppe: Menge der Teilnehmer, die die n Nachrichten gesendet haben. ± Umkodierte Ausgabenachrichten werden umsortiert (z.b. lexikographisch) ausgegeben. Jeder kann deterministische Ausgabereihenfolge auf Korrektheit ŸberprŸfen.

30 >> Warum sammeln und umsortieren? z Reihenfolge zwischen E- und A-Nachrichten mu unabhšngig sein z 3 Speicher- und Ausgabestrategien Ö Strategie 2: Pool (Cottrel, 1995) ± Jede gÿltige E-Nachricht landet nach Umkodierung in einem Nachrichtenpool der Grš e n. ± Durch ÈVerdrŠngungÇ wird eine im Pool vorhandene Nachricht zufšllig ausgegeben. ± Vorteil: Verschleifung der AnonymitŠtsgruppe Ÿber allen bisherigen Eingabenachrichten, im Mittel sinkt die Verweilzeit ± Nachteil: Ausgabezeitpunkt einer Nachricht wird indeterministisch

31 >>> Warum sammeln und umsortieren? z Reihenfolge zwischen E- und A-Nachrichten mu unabhšngig sein z 3 Speicher- und Ausgabestrategien Ö Strategie 3: R er, Stop-and-Go (Kesdogan et. al., 1998) ± Jede gÿltige E-Nachricht enthšlt ein vom Absender bestimmtes (absolutes) Zeitfenster fÿr die Ausgabe der Nachricht. ± Wenn das Zeitfenster Ÿberschritten ist, wird die Nachricht weggeworfen. ± Die umkodierte Nachricht landet in einem Puffer und mu innerhalb des Zeitfensters ausgegeben werden. ± Vorteil: Der Ausgabezeitpunkt ist deterministisch und vom Sender bestimmbar. ±Nachteil: Bei wenig Verkehr kann es vorkommen, da der Mix nur eine einzige Nachricht bearbeitet, wodurch diese nicht mehr unbeobachtbar ist.

32 > Warum È...von genÿgend vielen Absendern?Ç Eine Nachricht ist unbeobachtbar in der Gruppe der Nachrichten, die nicht vom Angreifer stammen. z Ziel: eine bestimmte Nachricht enttarnen Flooding-Attack z Angriff 1: Angreifer in Rolle ÈTeilnehmerÇ Ö Der Angreifer flutet den Mix mit eigenen Nachrichten, so da im Idealfall die eine zu beobachtende Nachricht und n-1 vom Angreifer bearbeitet werden. (n ist die Schubgrš e) z Angriff 2: Mix greift an Ö Angreifender Mix blockiert die n-1 uninteressanten Nachrichten und ersetzt diese durch eigene z Beobachtung des Outputs des folgenden Mixes fÿhrt zur berbrÿckung des Mixes, da n-1 Nachrichten dem Angreifer bekannt sind.

33 >> Warum È...von genÿgend vielen Absendern?Ç Verhindern der Flooding-Attack z Verhindern Angriff 1: Angreifer in Rolle ÈTeilnehmerÇ Ö Jeder Teilnehmer darf nur begrenzte Zahl Eingabenachrichten liefern. Ö Authentisierung der Eingabenachricht gegenÿber erstem Mix z Verhindern Angriff 2: Mix greift an Ö Broadcast-Feedback: Alle Teilnehmer erhalten alle AusgabeschŸbe aller Mixe zur Kontrolle. Wenn die eigene Nachricht fehlt, wird Alarm geschlagen. Ö Ticket-Methode: Jeder Teilnehmer erhšlt fÿr jeden Mix ein ÈTicketÇ (blind geleistete Signatur). Durch organisatorische Ma nahmen wird sichergestellt, da jeder Teilnehmer je Schub genau 1 Ticket erhšlt, also den Mix nicht mehr fluten kann. Ö Hashwert-Methode: Verhindert, da Nachrichten aus dem Schub entfernt werden, indem Hashwerte der Eingabenachrichten bitweise Ÿberlagert (XOR-verknŸpft) und mit einem Referenzwert verglichen werden.

34 > Indirektes Umkodierschema / Hybride Mixe z Direktes Umkodierschema fÿr SenderanonymitŠt: Ö N m+1 = c m+1 (N) Ö N i = c i (r i, A i+1, N i+1 ) fÿr i = m... 1, m:anz.mixe Ö Nachricht an ersten Mix: A 1, N 1 z Der Nachrichtenraum ist wegen asymmetrischer Kryptographie stark beschršnkt. z Gesucht ist ein Umkodierschema, bei dem die Nachricht beliebig lang sein darf: (indirektes Umkodierschema fÿr SenderanonymitŠt) Ö N m+1 = c* m+1 (N) Ö N i = c* i (r i, A i+1, N i+1 ) fÿr i = m... 1, m:anz.mixe c(n) falls N < BlocklŠnge Ö c* i (N) = c(k,nô),k(nôô) falls N < BlocklŠnge mit N=NÔ+NÔÔ z Beispiel: (m=3 Mixe) Ö N 1 = A 1, c 1 (k 1 ), k 1 (A 2, c 2 (k 2 ), k 2 (A 3, c 3 (k 3 ), k 3 (A E, c E (k E ), k E (N))))

35 > EmpfŠngeranonymitŠt z Problemstellung: Realisierung eines ÈReply-BlocksÇ A z Bilden des Reply-Blocks: (Anonyme RŸckadresse) Ö R m+1 = e e: ÈAdresskennzeichenÇ Ö R j = c j (k j, A j+1, R j+1 ) fÿr j = m... 1, m:anz.mixe Ö (k 0, A 1, R 1 ) ist der Reply-Block z B erhšlt den Reply-Block z.b. Ÿber ein per SenderanonymitŠt geschÿtzte Nachricht, ein Èschwarzes BrettÇ oder Broadcast. z Verwenden des Reply-Blocks: Ö N 1 = R 1, I 1 I 1 = k 0 (I) Ö N j = R j, I j I j = k j-1 (I j-1 ) fÿr j=2... m+1 z A erhšlt: Ö R m+1, I m+1 I m+1 = k m (...(k 1 (k 0 (I)))...) z Adresskenzeichen e (= R m+1 ) dient zum Wiederauffinden der k j z Anonyme RŸckadresse nur durch indirektes Schema realisierbar z Jede anonyme RŸckadresse kann nur einmal verwendet werden. B B soll A erreichen kšnnen ohne zu wissen, wer A ist.

36 > Freie Mix-Folge vs. Mix-Kaskade FREIE FOLGE z Nutzer wšhlt sich die Reihenfolge und Anzahl zu verwendender Mixe selbst z Vorteil: Ö Mehr VariabilitŠt z Nachteile: Ö etwas unsicherer als Mix- Kaskade (weniger Angriffsmšglichkeiten) Ö Nachrichten mÿssen lšngentreu sein, d.h. man sieht der Nachricht nicht an, wieviele Mixe sie bereits durchlaufen hat bzw. noch durchlšuft MIX-KASKADE z Sowohl Reihenfolge als auch Anzahl wird durch die Betreiber der Mixe festgelegt z Vorteile: Ö etwas hšhere Sicherheit, Ö kein Aufwand fÿr LŠngentreue, Ö Adressen der Mixe werden eingespart z Nachteile: Ö weniger VariabilitŠt, Ö bei Ausfall eines Mixes wird die gesamte Kaskade unverfÿgbar

37 > LŠngentreue Mixe z Motivation Ö Nachrichten verkÿrzen sich auf ihrem Weg durch die Mixe Ö Alle Nachrichten eines Schubes mÿssen jedoch gleich lang sein. z Vorgehen (SenderanonymitŠt) Ö Zerlege Nachricht I in b Blšcke, deren LŠnge auf das asymm. Kryptosystem abgestimmt ist: I = [m 1 ] [m 2 ]... [m b ] Ö Generiere m (Anz. der Mixe) symm. SchlŸssel k i (i=1...m) Ö VerschlŸssle I blockweise mit einem lšngentreuen symm. Kryptosystem: I 1 = k 1 (k 2 (...k m ([m 1 ])... k 1 (k 2 (...k m ([m b ]) = [k 1 (k 2 (...k m (m 1 )]... [k 1 (k 2 (...k m (m b )] Ö Header: (wšchst pro Schritt um einen Block) H k+1 = [e] H i = [c i (k i, A i+1 )], k i (H i+1 ) fÿr i = m... 1, m:anz.mixe Ö Sender sendet (A 1, H 1, I 1 )

38 >> LŠngentreue Mixe z Verarbeitung durch Mix Ö Header verkÿrzt sich um einen Block, deshalb AuffŸllen um einen Block Zufallszahlen N i = H i, I i mit I i := k i-1 (I i-1 ), [Z i-1 ] fÿr i = 2... m+1 z Beispiel (m=3 Mixe, b=2 Nachrichtenblšcke) N an Mix 1 A 1 c 1 (k 1,A 2 ) k 1 (c 2 (k 2,A 3 )) k 1 (k 2 (c 3 (k 3,A E ))) k 1 (k 2 (k 3 (m 1 ))) k 1 (k 2 (k 3 (m 2 ))) N an Mix 2 A 2 c 2 (k 2,A 3 ) k 2 (c 3 (k 3,A E )) Z 1 k 2 (k 3 (m 1 )) k 2 (k 3 (m 2 )) N an Mix 3 A 3 c 3 (k k,a E ) k 2 (Z 1 ) k 3 (m 1 ) k 3 (m 2 ) Z 2 N an E A E k 3 (k 2 (Z 1 )) k 2 (Z 2 ) Z 3 m 1 m 2

39 > Echtzeitkommunikation und Mixe z Mixe sind gut geeignet fÿr wenig zeitkritische Dienste: Ö z FŸr Echtzeitkommunikation (http, ftp) sind Modifikationen nštig: Ö Nachrichten sammeln fÿhrt zu starken Verzšgerungen, da der Mix die meiste Zeit auf andere Nachrichten wartet Ö NachrichtenlŠngen und Kommunikationsdauer variieren bei verbindungsorientierten Diensten stark z VerŠnderungen nštig Hohe Verzšgerungen in Zeiten niedrigen Verkehrsaufkommens: Maximale Nachrichtenanzahl oder maximale Wartezeit Ÿberschritten Ankunft (unabhšngig, exponentialverteilt) Verarbeitung Ausgabe t

40 > Traffic padding z Ziel: Verbergen, wann eine Kommunikation beginnt und endet z Problem: Niemand wei, wann der letzte Nutzer seine Kommunikation beenden mšchte User 1 User 2... Warten Traffic padding 1. Warten, bis genÿgend Benutzer kommunizieren wollen (Bilden der AnonymitŠtsgruppe) Beispiel: 5 Nutzer 2. Nach Kommunikationsende senden die Nutzer solange Zufallszahlen, bis der letzte Nutzer seine Kommunikation beendet. 3. Problem: Niemand wei, wann der letzte Nutzer seine Kommunikation beenden mšchte, da niemand echte Nachrichten von Traffic padding unterscheiden kann. t

41 > Zeitscheiben und Traffic padding z Lšsung: Zerlegen der Kommunikation in kleine Scheiben, genannt Zeitscheiben oder Volumenscheiben Ö Unbeobachtbarkeit innerhalb der Gruppe aller Nachrichten einer Zeitscheibe Ö LŠngere Kommunikationsverbindungen setzen sich aus mehreren Zeitscheiben zusammen Ö Zeitscheiben sind nicht verkettbar fÿr Angreifer Warte t Zeitscheibe Traffic padding

42 > Dummy traffic z Ziel: Verkehrsaufkommen in Situationen niedrigen Verkehrs kÿnstlich erhšhen, um AnonymitŠtsgruppe zu vergrš ern dummies Ankunft Verarbeitung Ausgabe t z Manchmal wird der Schub nicht voll, weil zu wenige Teilnehmer Nachrichten senden mšchten z Auswege: Ö Warten, bis weitere Nachrichten eintreffen (fÿhrt zu weiteren Verzšgerungen) Ö Akzeptieren, da AnonymitŠtsgruppe klein bleibt Ö Nutzer, die nichts zu senden haben, senden bedeutungslose Nachrichten z Def.: Dummy traffic. Ein Nutzer sendet stšndig Daten. Wenn er keine (verschlÿsselten) Nachrichten zu senden hat, sendet er Zufallszahlen, die nicht unterscheidbar sind von echten verschlÿsselten Nachrichten.

43 >> Dummy traffic z Verkehrsaufkommen in Situationen niedrigen Verkehrs kÿnstlich erhšhen dummies Ankunft Verarbeitung Ausgabe t z Dummy traffic nur zwischen Mixen reicht nicht aus users Mix Mix Mix z Dummy traffic mu Ende-zu-Ende generiert werden users Mix Mix Mix

44 > Probleme bei Langzeitbeobachtung z Schnittmengenangriff: Vom Angreifer beobachtete Online-Offline- Phasen kšnnen vom Angreifer genutzt werden, um Schnittmengen von AnonymitŠtsgruppen zu bilden. z Beispiel: Ö Ein Nutzer zeigt ein sehr konstantes Online-Offline-Verhalten (z.b. online von Uhr tšglich) Ö In dieser Zeit ruft er regelmš ig bestimmte Inhalte ab (Webseiten, seinen -Account) Ö Eine gro e Anzahl weiterer Internetnutzer ist ebenfalls zu dieser Zeit aktiv. z Der Angreifer beobachtet alle Kommunikationsleitungen, ohne in Mixe einzudringen. Langzeitbeobachtung fÿhrt zu unterschiedlichen AnonymitŠtsgruppen wšhrend der relevanten Zeit, die geschnitten werden. z Wie lange es dauert, die Aktionen eines Benutzers zu verketten, hšngt von der Gruppengrš e und dem Benutzerverhalten ab. z Simulation des Schnittmengenangriffs (Berthold, 1999) z Derzeit ist kein Schutz vor Schnittmengenangriffen in Sicht.

45 > Praxis: Anonymisierung im Internet z Anonymisierung von Electronic-Mail: Ö Typ-0-R er: anon.penet.fi ± Header entfernen und anonym/pseudonym weiterleiten ± Reply mšglich, da der echte Absender gespeichert und durch ein Transaktionspseudonym ersetzt wurde ±Verkettbarkeit Ÿber LŠnge und zeitliche Korrelation Ö Typ-1-R er: Cyperpunk-R er ± wie Typ-0, zusštzlich Angabe Ÿber Verzšgerungszeit bzw. Sendezeit, Kaskadierung ± PGP-verschlŸsselte Mails werden vom R er entschlÿsselt ±Verkettbarkeit Ÿber LŠnge, bei niedrigem Verkehrsaufkommen auch Ÿber zeitliche Korrelation Ö Typ-2-R er: Mixmaster (Cottrell, 1995) ± sammeln von Nachrichten ±Mix-Modell im Pool-Mode ± alle Nachrichten haben gleiche LŠnge

46 > Anonymisierung von Verbindungen (HTTP, FTP) z Client-AnonymitŠt Ö Einfache Proxies (teilweise mit Filterfunktion: Cookies, JavaScript, active content) ± Anonymizer.com (Lance Cottrel) ±Aixs.net ± ProxyMate.com (Lucent Personal Web Assistant, Bell Labs) ± Rewebber.com (Andreas Rieke, Thomas Demuth, FernUni Hagen) ±Jeder entsprechend konfigurierte Web-Proxy Ö Verkehrsanalysen berÿcksichtigende Verfahren ± Onion-Routing (Naval Research Center) ± Crowds (Mike Reiter, Avi Rubin AT&T) ±Freedom (Ian Goldberg, Zero-Knowledge Inc.) ±WebIncognito (Privada) ± Web-Mixe/JAP (TU Dresden)

47 > Anonymisierung von Verbindungen (HTTP, FTP) z Server-AnonymitŠt Ö Rewebber Network und TAZ (Temporary Autonomous Zone) Servers (UC Berkeley, Ian Goldberg, Dave Wagner) Ö Rewebber.com vormals ÈJanusÇ (FernUni Hagen, Andreas Rieke, Thomas Demuth) 7Qv3FJlRbyej_Wh10g_9vpPAyeHmrYE1 a4uyt3iaqeqrxxd7oxevwr8wj3cnrnbp IWUtlgW0uRlL0bGkAv3fX8WEcBd1JPWG PL7OvuV0xtbMPsRbQg0iY=RKLBaUYeds WTE1nuoh_J5J_yg1CfkaN9jSGkdf51-g Vyxfupgc8VPsSyFdEeR0dj9kMHuPvLiv f8mc44qbn0fmvjjpeyhsa79kdtq5eglp cnlsd7ylsc1gki3x8nk15s=rxbqaqm0a _MMJaz9wchn_pI48xhTzgndt5Hk09VTo XKPD7YbKVyiDZytva_sUBcdqpmPXTzAp o1pu1rky8cxrfnc9bvqqof853n99vkug 6i8DOat-NrOIndpz5xgwZKc=/

48 > Randbedingungen Ñ Beispiel z Profil der Dienstnutzung Ö Online-/Offline-Phasen Ö Gleicher Nutzer besucht gleiche Webseite hšufiger ±Aktionen verkettbar z Cookies und andere dienstspezifische Verkettungsmerkmale Ö ZusŠtzlicher Filter nštig ±Aktionen verkettbar fÿr Server z Java und JavaScript im Browser aktiviert Ö IP-Adresse kann abgefragt und Ÿbermittelt werden ±Teilnehmer u.u. identifizierbar durch Server Trotz Einsatz eines perfekten Grundverfahrens

49 > Einfache Proxies z Server besitzt keinerlei Information Ÿber den wirklichen Absender eines Requests z Kein Schutz gegen den Betreiber des Proxy z Kein Schutz gegen Verkehrsanalysen z Arbeitsprinzipien fÿr Webzugriff: 1. Formularbasiert Ö URL eingeben Ö Proxy stellt Anfrage und versieht eingebettete URLs mit einem PrŠfix 2. Browserkonfiguration Šndern Ö Èuse proxyç

50 >> Einfache Proxies Nutzer 1 Nutzer 2. Nutzer x GET page.html http-proxy GET page.html Webserver. INTRANET INTERNET z Beobachtung und Verkettung ist mšglich Ö zeitliche Verkettung Ö Verkettung Ÿber Inhalte (Aussehen, LŠnge) VerschlŸsselung zwischen Browser und Proxy verhindert Korrelation Ÿber ÈAussehenÇ, aber nicht Ÿber NachrichtenlŠnge und Zeit und hilft nichts gegen den Proxy.

51 > Crowds z Webanfrage wird mit einer Wahrscheinlichkeit P direkt an Server geschickt oder alternativ (mit 1-P) an anderen Teilnehmer (Jondo) z Symmetrische VerbindungsverschlŸsselung zwischen den Nutzern Ö Verkettung Ÿber Kodierung verhindern Ö Jedoch zeitliche Verkettung mšglich z Eingebettete Objekte (Images etc.) werden vom letzen Jondo angefordert. Ö Anfrage-Bursts unterbinden z Sicherheitseigenschaft: Nutzer kann stets behaupten, sein Initiator Jondo habe die Anfrage zur Weiterleitung erhalten z SchwŠche: zeitliche Korrelationen bleiben erhalten AT&T

52 > Onion Routing US Naval Research Center, Syverson et. al, 1996 z Ziel des Projektes: Schutz von Routing-Information in verbindungsorientierten Diensten z Mix-basiert mit Verfallszeit fÿr die Datenbank z Dummy Traffic zwischen Mixen (Onion-Routern) z First-Hop-Last-Hop-Attack: Verkettung von Anfangs- und Endpunkt einer Kommunikation (bei geringer Verkehrslast) mšglich Ö Zetliche Verkettung Ö NachrichtenlŠnge X exp_time X, Y, key_seed X, Y exp_time Y, Z, key_seed Y, Z exp_time Z, NULL, key_seed Z, Jede ÈSchaleÇ ist mit dem public key des nšchsten Onion-Routers verschlÿsselt

53 > Vergleich Zeitliche Verkettung Verkettung über Inhalt Anonymizer keine Vorkehrungen dagegen keine Vorkehrungen, lediglich Headerinformationen werden entfernt Crowds keine Vorkehrungen, aber wenigstens Zusammenfassung von Anfragen in Jondos keine Vorkehrungen, aber wenigstens sind Inhalte verschlüsselt Onion Routing schwache Vorkehrungen, lediglich Dummy-Traffic zwischen Onion- Routern für Kanalaufbau keine Verkettung, für Datenaustausch jedoch Verkettung über Nachrichtenlänge möglich

54 > Andere Konzepte z Privada WebIncognito Ö keinerlei Angaben zum technischen Konzept Ö Èis based on a patent-pending technologyç z Zero-Knowledge Freedom Ö Mix-basiert (Anonymous Internet Proxy, AIP) Ö Dummy Traffic zwischen Mixen Ö Link Padding Envelope Shaper ± BerŸcksichtigung des Nutzerverhaltens und der Verkehrssituation bei der Generierung von Dummy Traffic z WebMixe/JAP Ö Mix-basiert Ö Dummy-Traffic von Teilnehmer Ö RŸckmeldung Ÿber Grš e der AnonymitŠtsgruppe Ö geplant: IdentitŠtsmanagement

55 > JAP/WebMixe

56 > WebMixe: Architektur Client 1 Browser Java Anon Proxy: Ð client software Ð platform independend Ð local proxy Ð constant dummy traffic Ð adaptive time-slices Ð tickets against flooding... JAP Anonymity group: Each client is unobservable in the group of n clients redundand Info Service requests Info Service unobservable data flow Info Server MIX MIX Info Server Secure reliable update and replication of Info Servers Information Service: Ð traffic situation Ð anonymity level Ð warnings MIX Cache Proxy Cascade of MIXes: Ð real-time deployable MIXes Ð different operators Ð different locations Ð cascade: fixed sequence of servers Ð secure against traffic analysis Ð for better performace: more than one cascade Server... Client n Browser JAP CA Certification Authority: Ð independend of Web Mixes System Ð issues certificates of public keys Server Web Server

57 > WebMixe: Zeitscheibenprotokoll Local proxy MIX MIX MIX Cache proxy Server {Get Server/Page.html} Get Server/Page.html response Create and store Sl {Response NIL, wait, Sl, Padding} IF (no answer from Server yet) AND (no timeout)) THEN send {Response Block[i], wait, Sl, Padding} IF not EOF send {Response Block[i], EOF, Sl, Padding} IF not EOF send {Get C-Proxy, Sl} ELSE send END ELSE send

58 Stop Big Brother! JAVA ANON PROXY ://anon.inf.tu-dresden.de

59 GET >please type in your name >set cookie >>> Web Mixes Anonymous communication secure against traffic analysis Information online? ±Demonstrations ±Downloads ±Links

60 GET >please type in your name >set cookie >>> E-Commerce und PseudonymitŠt E-Commerce Ð Aufbau eines E-Shopping- Systems PseudonymitŠt Ð Verfahren fÿr Pseudonyme Transaktionen Pseudonyme Ð Skalierbarkeit bzgl. des Schutzes Anwendungen Ð Pseudonyme Bestellungen Ð Nym-Erzeugung in Freedom

61 > Aufbau eines E-Shopping Systems Kunde K Shopadministation, HŠndler Storefront-Requests Backoffice-Requests Internet Storefront Backoffice Intranet Webadapter Application Server Catalog- Server Transaction- Server Datenbank Erweiterungsmodule

62 > Pseudonyme: Implementierungen z Pseudonym-Arten Ö Vom Teilnehmer selbst gewšhlte Zeichenketten, die keinen Bezug zu seiner IdentitŠt besitzen Ö Gro e Zufallszahlen (etwa 45 Dezimalstellen) Ö ffentliche TestschlŸssel eines Signatursystems z Pseudonyme zur BestŠtigung von Eigenschaften Ö Einfaches Èqualifizierendes ZertifikatÇ Ö Blenden des Pseudonyms vor dem Zertifizieren Ö Secret-key Zertifikate BEGIN ZERTIFIKAT Pseudonym: Öffentlicher Testschlüssel des Pseudonyms: h833hd38dddajscbicme098342k236egfkw74h hdbscldmrtpofjrkt0jshuedagaszw12geb3u4b= Bestätigte Eigenschaften: Der Inhaber ist über 18 Jahre alt. Der Inhaber ist deutscher Staatsbürger. Datum: Gültig bis: Aussteller: Einwohnermeldeamt Dresden Signatur des Ausstellers: 23j423vdsaz345kj435ekji3u4z ijo23i72 kj867wdbez2o074j5lkdmcdkki1237t3rgbdvbwdj= END ZERTIFIKAT

63 Signatursystem fÿr PseudonmitŠt verwenden TestschlŸssel t ist das Pseudonym: Zufallszahl Text mit Signatur und Testergebnis x, Sig(x), Testen ãokò oder ãfalschò t SchlŸssel zum Testen der Signatur, šffentlich bekannt Text mit Signatur x, Sig(x) SchlŸsselgenerierung s Signieren SchlŸssel zum Signieren, geheimgehalten Text x Bereits heute realisierbar mit PGP: Pretty Good Privacy (PGP):

64 > Pseudonyme: Systematik Personenpseudonyme Rollenpseudonyme anonyme šffentliche nichtšffentliche GeschŠftsbeziehungspseudonym Transaktionspseudonym Skalierbarkeit bezÿglich des Schutzes AÊn o n y m i t Š t

65 >> Pseudonyme: Beispiele Personenpseudonyme Rollenpseudonyme Transaktionspseudonym Telefonnummer Kontonummer anonyme šffentliche nichtšffentliche GeschŠftsbeziehungspseudonym Biometrik,DNA (solange kein Register) KŸnstlername Kennwort Skalierbarkeit bezÿglich des Schutzes AÊn o n y m i t Š t

66 > Verfahren fÿr pseudonyme Transaktionen z Wer ist zu schÿtzen? Ö Kunde Ö HŠndler Ö Bank Ö É z Grundkonzepte: Kunde Bank Ö PseudonymitŠt, d.h. dig. Signaturen relativ zu Pseudonym = šffentl. TestschlŸssel ± Identifizierung im Betrugsfall (Zertifizierungsinstanz, die IdentitŠt kennt): nicht kontrollierbar ± Geldhinterlegung fÿr Haftung (aktiver TreuhŠnder): kontrollierbar Ö Werteaustauschprotokolle Ö Digitale Zahlungssysteme Ö Umrechenbare Beglaubigungen (Credentials) HŠndler

67 > Pseudonyme Bestellung von (digitalen) Waren Voraussetzung: existierende Infrastruktur fÿr Signatur 2. registriert P: K, P, sig K ( K, P) Trusted Third Party TTP speichert: K, P, sig K ( K, P) Im Streitfall: HŠndler fordert IdentitŠt zu P an und legt sig P bei 4. erhšlt Zertifikat: sig TTP (P) Bei berechtigtem Interesse: TTP liefert IdentitŠt K zu P HŠndler Kunde K 1. K generiert SignaturschlŸsselpaar: P=šff. TestschlŸssel 5. Bestellung, P, sig P (Bestellung, P), sig TTP (P) 6. Ware 7. ÈGeldÇ 8. Quittungen

68 ÈNymÇ-Erzeugung in Freedom Teilnehmer Teilnehmer kauft sich eine Seriennummer 1. Nym-Anforderung, Kreditkartennummer Seriennummer SN Zahlung per Kreditkate oder Scheck, Seriennummer SN wird erst freigeschaltet, wenn Zahlung erfolgt ist. 2. WWW-Shop Betreiber: Freedom/ ZKS Teilnehmer lšst SN ein und erhšlt ein Nym- Token 3. {SN} Nym-Token Freedom-Netz SN {Nym-Token} Nym-Token: Digital signierte Berechtigungsmarke zur Benutzung des Freedom-Netzes unter einem Nym. 4. Trusted Third Party: Token-Server Betreiber: UnabhŠngiger Dritter (Trusted Third Party) Teilnehmer generiert sich ein Nym 5. Freedom-Netz {Nym Token, Nym} Nym Token, Nym BestŠtigung 6. Nym-Server Betreiber: Freedom/ ZKS Das Freedom-Netz schÿtzt die Kommunikationsbeziehungen zwischen Teilnehmer und Server.