Hannes Federrath, Andreas Pfitzmann

ãNeueÒ AnonymitŠtstechniken

Eine vergleichende †bersicht

Hannes Federrath, Andreas Pfitzmann

Der Beitrag bewertet die Sicherheit von Crowds, Anonymizer und Onion Rou- ting, also Systemen zur UnterstŸtzung von Client-AnonymitŠt im World Wide Web. Je nach unterstellter StŠrke des Angreifers kann sich ein Nutzer mit diesen Techniken gezielt schŸtzen.

[FOTO] Dr. Hannes

Federrath

Wissenschaftlicher Mitarbeiter an der TU Dresden, Fakul- tŠt Informatik, For- schungsschwerpun kt ist die Sicherheit in verteilten Syste- men

E-Mail: federrath@inf.tu-dresden.de

[FOTO] Prof. Dr. Andreas

Pfitzmann

TU Dresden, Fakul- tŠt Informatik, For- schungsschwerpun kt ist technischer Datenschutz durch verteilte Systeme E-Mail: pfitza@inf.tu-dresden.de

Einleitung

ZunŠchst werden einige zum VerstŠndnis der vorgestellten AnonymitŠtstechniken wichtige Begriffe wie AnonymitŠt, Unbe- obachtbarkeit und Unverkettbarkeit defi- niert. Anschlie§end werden die bekann- ten Standardtechniken systematisiert und kurz vorgestellt. Am Beispiel der Mixe wird gezeigt, wie solche Techniken funk- tionieren.

In Abschnitt 2 wird das Angreifermo- dell beschrieben, das der Bewertung der anschlie§end vorgestellten Verfahren zu- grunde liegt. In Abschnitt 3 werden die Verfahren vorgestellt und bezŸglich ihrer erreichten Sicherheit verglichen.

1.1 Begriffe

AnonymitŠt und Unbeobachtbarkeit sind Forderungen nach Vertraulichkeit von Daten. Vertraulichkeit allgemein kann sich auf zwei Bereiche beziehen. Es kšn- nen sowohl

n die Nachrichteninhalte als auch n die sogenannten Kommunikationsum-

stŠnde

schŸtzenswert sein.

Die Vertraulichkeit von Nachrichten- inhalten erreicht man normalerweise durch VerschlŸsselung. SchŸtzenswerte KommunikationsumstŠnde kšnnen sein:

n ^das Senden einer Nachricht, n das Empfangen einer Nachricht, n ^eine Kommunikationsbeziehung zwi-

schen zwei oder mehr Teilnehmern, n der Aufenthaltsort der Teilnehmer.

Dabei ist in der Regel jeweils noch der Zeitpunkt des Vorgangs ein wichtiger Umstand. Bei jeder Kommunikation fallen nun sogenannte Verkehrsdaten (Beginn und Ende der Kommunikation, eindeutige Kennungen der Kommunikationspartner,

Umfang der Kommunikation) an, die ei- nem Angreifer Informationen Ÿber diese KommunikationsumstŠnde geben kšnnen.

In [Pfit_90] wurden Definitionen fŸr die Begriffe Unbeobachtbarkeit und An- onymitŠt angegeben, die hier in etwas vereinfachter Form verwendet werden sol- len.

Unbeobachtbarkeit bedeutet, da§ fŸr einen Angreifer die Wahrscheinlichkeit des Auftretens eines Ereignisses (z.ÊB.

Senden einer Nachricht) nach jeder Beob- achtung sowohl echt grš§er 0 als auch echt kleiner 1 ist. Perfekte Unbeobacht- barkeit bedeutet, da§ fŸr einen Angreifer die Wahrscheinlichkeit des Auftretens eines Ereignisses vor und nach jeder Be- obachtung gleich ist.

AnonymitŠt bedeutet, da§ fŸr einen Angreifer die Wahrscheinlichkeit, da§ ei- ne Instanz (z.ÊB. eine Person) bei einem Ereignis eine bestimmte Rolle (z.ÊB. Sen- der der Nachricht) wahrnimmt, nach jeder Beobachtung sowohl echt grš§er 0 als auch echt kleiner 1 ist. Perfekte Anonymi- tŠt bedeutet, da§ fŸr einen Angreifer die Wahrscheinlichkeit, da§ eine Instanz bei einem Ereignis eine bestimmte Rolle wahrnimmt, vor und nach jeder Beobach- tung gleich ist.

1.2 Standardtechniken

Aus PlatzgrŸnden mu§ in diesem Beitrag darauf verzichtet werden, die Standard- techniken zur AnonymitŠt in aller Aus- fŸhrlichkeit zu behandeln.¹ Es wird je- doch im folgenden eine Systematik ange- geben und jede Technik kurz erlŠutert.

n Schutz des EmpfŠngers

n Verteilung (Broadcast): Um den Empfang einer Nachricht zu verber- gen, werden Nachrichten an alle Teilnehmer verteilt. Eine Auswahl

1ÊEine †bersichtsdarstellung findet sich in Roessler, in diesem Heft.

der Nachrichten erfolgt lokal beim EmpfŠnger. Beispiel: Rundfunk- empfang.

n Implizite Adressen: Soll trotz Ver- teilung eine Punkt-zu-Punkt- Kommunikation erreicht werden, mu§ der EmpfŠnger Ÿber sog. impli- zite Adressen adressiert werden.

Implizite Adressen sind Bitketten, an denen nur der EmpfŠnger er- kennt, da§ eine Nachricht fŸr ihn bestimmt ist. FŸr alle anderen Teil- nehmer (inkl. Angreifer) sind sie mit nichts und niemandem verkettbar.

Beispiel: Ein Teilnehmer wŠhlt sich eine Zufallszahl und teilt diese den potentiellen Sendern (z.B. in einer Chiffreanzeige) mit.

n Schutz des Senders

n Dummy Traffic: Soll verborgen werden, ob ein Teilnehmer gerade eine Nachricht senden mšchte, mu§

er immer senden. Solange er keine Nachrichten zu senden hat, sendet er Leernachrichten, die sich fŸr ei- nen Au§enstehenden nicht von echten Nachrichten unterscheiden.

n DC-Netz: Das DC-Netz [Chau_88]

schŸtzt den Sender einer Nachricht.

So kann ein Teilnehmer eine Nach- richt senden, ohne da§ er als Sender erkannt wird. Der Teilnehmer ist innerhalb einer Gruppe, der sog.

AnonymitŠtsgruppe, anonym.

n Schutz der Kommunikationsbezie- hung zwischen Teilnehmern

n Mixe: Mixe [Chau_81] schŸtzen die Kommunikationsbeziehung, indem sie die Verkettung der Endpunkte einer Kommunikationsverbindung verhindern. Auch hier ist der Teil- nehmer innerhalb einer Anonymi- tŠtsgruppe geschŸtzt.

n Schutz der Aufenthaltsorte von mobi- len Teilnehmern

n Verteilung (Broadcast): Werden Nachrichten in das gesamte Aufent- haltsgebiet verteilt, ist auch der Aufenthaltsort des mobilen Teil- nehmers geschŸtzt [Pfit_93].

n Pseudonymisierung: Aufenthalts- daten werden beim Netzbetreiber unter einem Pseudonym gespei- chert. Die Verkettung zwischen der IdentitŠt und dem Pseudonym unterliegt der Kontrolle des Teil- nehmers [KeFo_95].

n Mobilkommunikationsmixe: Auch hier schŸtzen die Mixe die Kommu-

nikationsverbindung, allerdings wird bereits die Signalisierverbin- dung zwischen den Aufenthaltsda- tenbanken und dem aktuellen Auf- enthaltsgebiet geschŸtzt [FeJP_96].

Weitere Informationen zu den Standard- mechanismen zum Schutz des Senders, des EmpfŠngers und der Kommunikationsbe- ziehung findet man z.B. in [FePf_97]. Zum Schutz der mobilen Teilnehmer siehe [Fede_98].

MIX M1

puffert Nachrichten, ignoriert Wiederholungen, sortiert Nachrichten um, kodiert sie um durch d1(c1(zi, mi)) = (zi, mi), ignoriert zi, gibt mi aus

MIX M2

c1(z4, c2(z1, m1)) c1(z5, c2(z2, m2)) c1(z6, c2(z3, m3))

c2(z3, m3) c2(z1, m1) c2(z2, m2)

puffert Nachrichten, ignoriert Wiederholungen, sortiert Nachrichten um, kodiert sie um durch d2(c2(zi, mi)) = (zi, mi), ignoriert zi, gibt mi aus

m2 m3 m1

Bild 1: Umkodieren zu mixender Nach- richten

Um einen optimalen Schutz der Teilneh- mer zu erreichen, mŸssen Sicherheitsme- chanismen miteinander kombiniert wer- den. Bei der Verteilung persšnlicher Nachrichten mu§ beispielsweise implizite Adressierung angewendet werden. Die Nachricht selber sollte verschlŸsselt sein.

1.3 Beispiel: Mixe

Die Idee der Mixe wurde in [Chau_81]

vorgestellt. Das Mix-Konzept kommt i n Vermittlungsnetzen zum Einsatz. Ein Mix verbirgt die Kommunikationsbeziehung zwischen Sender und EmpfŠnger einer Nachricht. Hierzu mu§ ein Mix eingehen- de Nachrichten speichern, bis genŸgend viele Nachrichten von genŸgend vielen Absendern vorhanden sind, ihr Aussehen

verŠndern, d.h. sie umkodieren, und die Reihenfolge der ausgehenden Nachrich- ten verŠndern, d.h. sie umsortieren und i n einem Schub ausgeben.

Um Angriffe durch Nachrichtenwie- derholung zu verhindern, mu§ zu Beginn noch geprŸft werden, ob eine eingehende Nachricht bereits gemixt wurde. Da ein Mix deterministisch umkodiert, wŸrde ei- ne Nachrichtenwiederholung z.ÊB. in ei- nem nŠchsten Schub zur Ausgabe der gleichen umkodierten Nachricht fŸhren.

Somit wŠre eine Verkettung von Ein- und Ausgabe mšglich.

Damit keine Verkettung zwischen ein- gehenden und ausgehenden Nachrichten Ÿber deren LŠnge mšglich ist, sollten alle Nachrichten die gleiche LŠnge haben.

Eine Nachricht, die einen Mix durch- lŠuft, ist nur innerhalb eines Schubes an- onym. Deshalb mu§ sichergestellt sein, da§ ein Angreifer nie alle Nachrichten au§er einer selbst erzeugt hat, denn das kŠme der Deanonymisierung gleich. Ar- beiten alle anderen Sender und EmpfŠnger der in einem Schub gemixten Nachrichten zusammen, sind die Kommunikationsbe- ziehungen ebenfalls aufdeckbar.

Falls nicht genŸgend eingehende Nachrichten vorhanden sind, mŸssen kŸnstliche erzeugt werden, damit die Ver- zšgerungszeit einer Nachricht minimiert wird (Dummy Traffic).

Die Kernfunktion eines Mixes ist das Umkodieren der Nachrichten. Hierzu wird mit Hilfe eines asymmetrischen Kryptosy- stems jede zu mixende Nachricht mit dem privaten SchlŸssel des Mixes entschlŸs- selt (umkodiert) und an den nŠchsten Mix weitergeschickt (Bild 1). Bei einem asymmetrischen Kryptosystem (z.ÊB. RSA) haben Sender und EmpfŠnger unterschied- liche SchlŸssel zum Ver- und EntschlŸs- seln. Der VerschlŸsselungsschlŸssel (public key) ist šffentlich bekannt, d.h.

jeder kann eine Nachricht fŸr den Emp- fŠnger verschlŸsseln. Den EntschlŸsse- lungsschlŸssel (private key) besitzt nur der EmpfŠnger (hier: der Mix) und nur er kann somit seine empfangenen Nachrich- ten entschlŸsseln.

Mehrere unabhŠngige Betreiber der zwischengeschalteten Mixe garantieren die Unbeobachtbarkeit der Kommunika- tionsbeziehungen. Solange mindestens ein Mix ãgutartigÒ ist (d.h. nicht mit den anderen zur Aufhebung der AnonymitŠt kooperiert), bleibt die Kommunikations- beziehung geschŸtzt.

Das Mix-Konzept war in den letzten zehn Jahren Gegenstand vieler For- schungsarbeiten, zum Teil mit Grundla- gencharakter, siehe z.ÊB. [PfWa_87, PfPW_88, Pfit_90, PfPf_90], aber auch mit einer deutlichen Anwendungsorien- tierung, siehe z.ÊB. [PfPW_89, Pfit_93, Cott_95, FeJP_96, FaKK_96, GoRS_96].

2 Angreifermodell

Aussagen Ÿber den erzielten Schutz kšn- nen nur im Zusammenhang mit der unter- stellten StŠrke eines Angreifers gemacht werden. Ein Angreifermodell gibt die ma- ximal mšgliche StŠrke des Angreifers an, gegen den der Schutz gerade noch ge- wŠhrleistet ist.

Bezogen auf die Beobachtbarkeit im In- ternet und speziell im World Wide Web wollen wir Schutz vor einem Angreifer er- reichen, der auf allen Leitungen alle Kommunikation abhšren kann.² Verkehr- sanalysen sind fŸr ihn mšglich. Auch In- sider (Nutzer/Beobachter im Intranet) werden als Angreifer betrachtet.

Eine Konsequenz fŸr den Schutz vor Beobachtbarkeit ist, da§ bei diesem An- greifermodell die Nutzung von http- Proxies (z.ÊB. Anonymizer, siehe Ab- schnitt 3.1) zur Verschleierung von Webanfragen nicht ausreicht (Bild 2), da der Angreifer auch im Intranet verbreitet sein kann.

Nutzer 1 Nutzer 2

Nutzer i .. . .. .

INTRANET INTERNET

http-Proxy GET

page.html

GET page.html

Beobachtung und Verkettung ist möglich – zeitliche Verkettung

– Verkettung über Inhalte (Aussehen, Länge)

Bild 2: Verbreitung des Angreifers

2ÊZwar ist dies eine strenge Annahme, wenn aber eine Kommunikationsbeziehung auch unter diesen Bedingungen anonym ist, kann auch ein schwŠcherer Angreifer die AnonymitŠt nicht aufheben.

3 Bewertung der ãneuenÒ Techniken

Durch die starke Verbreitung des Internet und die zunehmende Abwicklung persšn- licher Kommunikation gewinnen die Entwicklung und insbesondere die Im- plementierung von Verfahren zur Unbe- obachtbarkeit und AnonymitŠt gro§e Be- deutung.

In folgenden sollen drei vergleichs- weise neue AnsŠtze, die den Schutz vor Beobachtung insbesondere im Internet gewŠhrleisten sollen, auf ihre Grenzen untersucht werden.

n Anonymizer (www.anonymizer.com), n ^Crowds

(www.research.att.com/projects/crowd n s),Onion Routing (www.onion-

router.net).

Obwohl alle drei AnsŠtze annŠhernd das gleiche Ziel verfolgen, unterscheiden sie sich insbesondere in dem erreichbaren Schutz, d.Êh. die Angreifermodelle der Verfahren sind unterschiedlich stark.

Ziel der Verfahren ist, gegenŸber dem Server und teilweise auch gegenŸber Be- obachtern, die Verkehrsanalysen durch- fŸhren, zu verbergen, wer welche Websei- ten aufruft (Client-AnonymitŠt).³

Die oben genannten Verfahren werden im folgenden kurz beschrieben und dann insbesondere im Hinblick auf den erreich- ten Schutz miteinander verglichen.

3.1 Anonymizer

Der ãAnonymizerÒ ist ein Proxydienst.

†ber ein Webinterface (einfacher Aufruf einer Webseite, in die eine URL eingege- ben werden mu§) kann der Dienst genutzt werden.

Der Nutzer mu§ dem Betreiber des An- onymizer vertrauen, da§ er keine Ver- kehrs- und Interessensdaten sammelt.

Theoretisch kšnnen mehrere Anonymizer hintereinander geschaltet (kaskadiert) werden. Dann wei§ nur noch der erste Anonymizer direkt, wer (genauer: welche IP-Adresse) den Dienst nutzt.

Technisch gesehen arbeitet der An- onymizer wie ein herkšmmlicher http- (Web-) Proxy, jedoch mit dem Unter- schied, da§ der Anonymizer alle potenti- ell personenbezogenen Informationen

3ÊZur AnonymitŠt des Servers siehe Demuth, Rieke, in diesem Heft.

(z.ÊB. Cookies) in den Headern der Webanfragen entfernt. VerschlŸsselung wird beim Anonymizer nicht verwendet.

BezŸglich eines Angreifers, der alle Kommunikation im Netz abhšren kann bzw. Verkehrsanalysen durchfŸhrt, ist der Anonymizer nicht sicher. Somit gelten sinngemŠ§ die Aussagen zu http-Proxys aus Abschnitt 2. Das bedeutet, die Anfragen kšnnen Ÿber das ãAussehenÒ der Nachrichten und deren LŠnge sowie die zeitlichen Korrelationen der ein- und ausgehenden Nachrichten verkettet wer- den. Au§erdem kann der Angreifer sofort alle Inhalte mitlesen, da keine VerschlŸs- selung verwendet wird.

Die Bemerkungen zum Anonymizer gelten auch fŸr andere einfache Proxys, z.B. den Lucent Personalized Web Assi- stant (LPWA, siehe www.bell- labs.com/project/lpwa/overview.html).

Der Nutzer mu§ dem System vollstŠndig vertrauen, da sŠmtliche Zugriffe und Daten von einer zentralen Instanz verwaltet werden.

3.2 Crowds

Crowds ãverstecktÒ die Webanfragen ei- nes Teilnehmers in denen der anderen Crowds-Dienstnutzer. Um am Dienst teil- zunehmen, meldet sich der Nutzer bei ei- ner zentralen Stelle, dem sogenannten Blender, an.

Auf dem lokalen Rechner hat jeder am Dienst teilnehmende Nutzer ein Pro- gramm installiert, den sogenannten Jondo.

Die Idee von Crowds ist, da§ eine Webanfrage nicht direkt an den Server ge- stellt wird, sondern vorher mehrere Jon- dos anderer Teilnehmer durchlŠuft. In je- dem Jondo wird eine Anfrage zufŠllig entweder zu einem weiteren Jondo ge- schickt oder direkt an den Server.

Ein negativer Aspekt von Crowds ist, da§ ein Teilnehmer fŠlschlicherweise fŸr den Absender einer Anfrage gehalten werden kann. Ein Vorteil ist jedoch, da§

ein Teilnehmer stets abstreiten kann, der Initiator einer Anfrage gewesen zu sein.

Ein Angreifer, der die Kommunikati- onsinhalte unmittelbar mitlesen will, hat bei Crowds im Gegensatz zum Anonymi- zer keine Mšglichkeit, da die Inhaltsda- ten zwischen den Jondos mit einem sym-

metrischen Kryptosystem⁴ verschlŸsselt sind.

Eine Verkettung Ÿber die LŠnge der (verschlŸsselten) Nachrichteninhalte und damit die Beobachtung ist jedoch nach wie vor mšglich, wenn der Angreifer Ver- kehrsanalysen durchfŸhrt. Gegen Angriffe Ÿber die zeitliche Verkettung von einge- henden Nachrichten eines Jondos und de- ren Ausgabe wurden keine Schutzma§- nahmen vorgesehen.

3.3 Onion Routing

Onion Routing beschrŠnkt sich nicht auf Webzugriffe. Es ist ebenfalls fŸr File- transfer (ftp), Remote Login und andere verbindungsorientierte Dienste nutzbar.

Es arbeitet als Proxydienst mit einem sog.

Initiator-Proxy auf der Nutzerseite und einem Responder-Proxy auf der dem Inter- net ãzugewandtenÒ Seite. Zwischen In- itiator- und Responder-Proxy sind mehre- re Onion-Router geschaltet.

Onion Routing soll folgendes Schutz- ziel erfŸllen: Ein Angreifer, der alle Kom- munikation im Netz abhšren kann, soll nicht in der Lage sein, ein- und ausge- hende Nachrichten eines Onion-Routers miteinander zu verketten. Dieses Angrei- fermodell entspricht praktisch dem von David Chaum aus [Chau_81]. Die techni- sche Lšsung fŸr das Onion Routing Šh- nelt Chaums Idee der Mixe sehr stark (siehe Abschnitt 1.3)

Chaum hatte damals fŸr seine Mixe die Elektronische Post (E-Mail) als Dienst gewŠhlt. Sie hat den Vorteil, nicht von Echtzeitanforderungen und Verbindun- gen abhŠngig zu sein. FŸr das World Wi- de Web benštigt man jedoch eine zumut- bare Verzšgerungszeit, bis die Antwort auf eine Anfrage im Browser zu sehen ist.

Daher waren Modifikationen des Gund- konzeptes notwendig, die zum Teil zu La- sten des erreichten Schutzes gehen.

Beim Onion Routing wird zunŠchst Ÿber eine Kanalaufbaunachricht (create) eine Onion (siehe Bild 3, Aufbau fŸr drei Onion-Router X, Y, Z) gesendet. Die Onion enthŠlt eine Zeitangabe (exp_time), die angibt, wann eine Onion verfŠllt. Die Zeitangabe dient der Abwehr von Nachrichtenwiederholungen. Solan- ge ^exp_time noch nicht abgelaufen ist, speichert der Onion-Router die Onion

4ÊBei einem symmetrischen Kryptosystem be- sitzen sowohl Sender als auch EmpfŠnger den gleichen SchlŸssel zum Ver- und EntschlŸsseln.

und testet auf Nachrichtenwiederholung.

Weiterhin enthŠlt die Onion die Adresse des nŠchsten Onion-Routers sowie SchlŸsselmaterial, das fŸr die nachfolgen- de Etablierung des ãanonymen KanalsÒ verwendet wird.

Bei Ihrem Lauf durch das Netz wird die Onion Schritt fŸr Schritt abgebaut, d.Êh.

im jeweiligen Onion-Router entschlŸs- selt, und gleichzeitig der anonyme Kanal aufgebaut. Hierzu merkt sich jeder Onion- Router, woher er eine Onion erhalten, wohin er die verbleibende Onion ge- schickt hat und zusŠtzlich ein Kennzei- chen, die sogenannte Pfad-ID. EmpfŠngt ein Onion-Router Daten fŸr eine bestimm- te ID, so verschlŸsselt er die erhaltenen Daten mit einem symmetrischen Krypto- system, dessen SchlŸssel er aus dem SchlŸsselmaterial (Key Seed) der Onion gewonnen hat.

exp_timex, Y, Key Seedx,

X

exp_timeY, Z, Key SeedY,

Y

exp_timeZ, NULL, Key SeedZ

Z

Jede „Schale“ ist mit dem public key des nächsten Onion-Routers verschlüsselt.

Bild 3: Aufbau einer Onion

Dummy Traffic wird nur zwischen den Onion-Routern erzeugt und bietet somit bei geringer Auslastung des Dienstes keinen (bzw. nur geringen) Schutz gegen Beobachtung, da die Enden eines Kom- munikationskanals allein Ÿber die ausge- tauschte Datenmenge verkettet werden kšnnen.

Da die Ÿber die anonyme Verbindung laufenden Daten eine beliebige LŠnge ha- ben kšnnen, ist eine Verkettung Ÿber die LŠnge der Ÿber den anonymen Kanal ge- sendeten Nachrichten mšglich.

4 Fazit und Ausblick

In Tabelle 1 werden die genannten Verfah- ren noch einmal nach dem erreichten Schutz gegenŸber Verkehrsanalysen zu- sammengefa§t.

Sofern Ÿberhaupt eine Metrik Ÿber dem er- reichten Schutz der drei vorgestellten Verfahren sinnvoll ist, kann man feststel- len, da§ Crowds gegen stŠrkere Angriffe schŸtzt als Anonymizer, und Onion Rou- ting stŠrker schŸtzt als Crowds.

David Chaum prŠsentierte 1981 in sei- nem Mixe-Artikel [Chau_81] eine Lš- sung, bei der aus der Sicht der Teilnehmer lediglich eine von n Parteien (n>1) ver- trauenswŸrdig sein mu§, damit der Teil- nehmer geschŸtzt ist. Im Grenzfall ist je- der Teilnehmer eine der n Parteien, und damit nehmen die Nutzer ihren Schutz i n die eigenen HŠnde. Dies geschieht z.ÊB.

bei Crowds.

Keines der hier vorgestellten Verfahren bietet perfekte AnonymitŠt. Die Verfahren erfŸllen nicht einmal das diesen Untersu- chungen zugrunde gelegte Angreifermo- dell (ãAlle Kommunikation ist Ÿber- wachbar.Ò)

Erste AnsŠtze zu einer Lšsung, die auch noch gegen das starke Angreifermo- dell schŸtzt, wurden in [FeMa_98] und auf der Cebit 1998 vorgestellt. Dort soll auch die zeitliche Verkettung und Verket- tung Ÿber die NachrichtenlŠnge nicht mehr mšglich sein. Angewendet wird eine Modifikation der Zeitscheiben der ISDN- Mixe (siehe [PfPW_89]). Beim Zeitschei- benmodell wird ein anonymer Kanal auf- gebaut, fŸr eine festgelegte Zeit bzw.

Nachrichtenmenge genutzt und anschlie-

§end wieder abgebaut. Dieser Proze§

wiederholt sich stŠndig und ein Teilneh- mer ist innerhalb der wŠhrend der Zeit- scheibe gemeinsam verarbeiteten Nach- richten anonym, da alle die gleiche Zeit bzw. NachrichtenlŠnge verwenden. Zwi- Zeitliche Verkettung Verkettung Ÿber Inhalt

Anonymizer keine Vorkehrungen dagegen keine Vorkehrungen, lediglich Hea- derinformationen werden entfernt Crowds keine Vorkehrungen, aber wenig-

stens Zusammenfassung von Anfra- gen in Jondos

keine Vorkehrungen, aber wenig- stens 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 Tabelle 1: Vergleich der Verfahren

schen den Zeitscheiben besteht keine Verkettung.

Literatur

Chau_81ÊÊDavid Chaum: Untraceable Electronic Mail, Return Addresses, and Digital Pseud- onyms. Communications of the ACM 24/2 (1981) 84-88.

Chau_88ÊÊDavid Chaum: The Dining Cryptogra- phers Problem: Unconditional Sender and Recipient Untraceability. Journal of Cryp- tology 1/1 (1988) 65-75.

Cott_95ÊÊLance Cottrel: Mixmaster & Remailer Attacks.

http://www.obscura.com/~loki/remailer- essay.html.

FaKK_96ÊÊAndreas Fasbender, Dogan Kesdo- gan, Olaf Kubitz: Scalable Security: Pro- tection of Location Information in Mobile IP. Proceedings of IEEE VTS 46th Ve- hicular Technology Conference, Atlanta, USA, April 28 - Mai 1, 1996 .

Fede_98ÊÊHannes Federrath: Sicherheit mobiler Kommunikation. erscheint bei Vieweg.

FeJP_96ÊÊHannes Federrath, Anja Jerichow, An- dreas Pfitzmann: Mixes in mobile commu- nication systems: Location management with privacy. in: R. Anderson (Hrsg.): In- formation Hiding, LNCS 1174, Springer- Verlag, Berlin 1996, 121-135.

FeMa_98ÊÊHannes Federrath, Kai Martius:

Mehrseitig sicherer Web-Zugriff. KES Zeit- schrift fŸr Kommunikations- und EDV- Sicherheit 14/4 (1998) 10-12.

FePf_97ÊÊHannes Federrath, Andreas Pfitzmann:

Bausteine zur Realisierung mehrseitiger Si- cherheit. in: GŸnter MŸller, Andreas Pfitz- mann (Hrsg.): Mehrseitige Sicherheit in der Kommunikationstechnik, Addison-Wesley- Longman 1997, 83-104.

GoRS_96ÊÊDavid M. Goldschlag, Michael G.

Reed, Paul F. Syverson: Hiding Routing In- formation. in: R. Anderson (Hrsg.), Infor- mation Hiding, LNCS 1174, Springer- Verlag, Berlin 1996, 137-150.

KeFo_95ÊÊDogan Kesdogan, Xavier Fouletier:

Secure Location Information Management in Cellular Radio Systems. Proc. IEEE Wi- reless Communication System Symposium 95, Long Island (1995), 35-46.

Pfit_90ÊÊAndreas Pfitzmann: Diensteintegrieren- de Kommunikationsnetze mit teilneh- merŸberprŸfbarem Datenschutz. IFB 234, Springer-Verlag, Heidelberg 1990.

Pfit_93ÊÊAndreas Pfitzmann: Technischer Daten- schutz in šffentlichen Funknetzen. Daten- schutz und Datensicherung DuD 17/8 (1993) 451-463.

PfPf_90ÊÊBirgit Pfitzmann, Andreas Pfitzmann:

How to Break the Direct RSA- Implementation of MIXes. Eurocrypt '89, LNCS 434, Springer-Verlag, Berlin 1990, 373-381.

PfPW_88ÊÊAndreas Pfitzmann, Birgit Pfitzmann, Michael Waidner: Datenschutz garantie- rende offene Kommunikationsnetze. Infor- matik-Spektrum 11/3 (1988) 118-142.

PfPW_89ÊÊAndreas Pfitzmann, Birgit Pfitzmann, Michael Waidner: Telefon-MIXe: Schutz der Vermittlungsdaten fŸr zwei 64-kbit/s- DuplexkanŠle Ÿber den (2x64 + 16)-kbit/s- Teilnehmeranschlu§. Datenschutz und Da- tensicherung DuD 13/12 (1989) 605-622.

PfWa_87ÊÊAndreas Pfitzmann, Michael Waid- ner: Networks without user observability. Computers & Security 6/2 (1987) 158-166.