Design Issues in Anonymity and Unobservability Workshop on

215 Pages·2000·1.84 MB·English

Hannes Federrath (Ed.)
Preproceedings of the
Workshop on
Design Issues in
Anonymity and
Unobservability
Attacks on Systems
Anonymous Publishing
Mix Systems
Identity Management
Pseudonyms & Remailers
International Computer Science Institute (ICSI)
Berkeley, California
July 25-26, 2000

Hannes Federrath (Ed.)
Proceedings of the
Workshop on Design Issues in Anonymity and Unobservability
International Computer ScienceInstitute(ICSI)
Berkeley, California
July 25-26,2000
ThisdocumentisalsoTechnicalReportTR-00-011ofICSI.
InternationalComputerScienceInstitute
1947CenterSt.,Suite600
Berkeley,CA94704-1198
Phone: [phone]
Fax: [phone]
http://www.icsi.berkeley.edu
Contents
TrafficAnalysis: Protocols,Attacks,DesignIssuesandOpenProblems ...........................7
Jean-Fran¸coisRaymond
ThedisadvantagesoffreeMIXroutesandhowtoovercomethem .............................. 27
OliverBerthold,RonnyStandtke,AndreasPfitzmann
Freenet: ADistributed AnonymousInformationStorageandRetrievalSystem ...................43
IanClarke,OskarSandberg,BrandonWiley, TheodoreW.Hong
TheFreeHavenProject: DistributedAnonymousStorageService ...............................59
RogerDingledine,MichaelFreedman,DavidMolnar
TowardsanAnalysisofOnionRoutingSecurity ...............................................83
PaulSyverson,GeneTsudik,MichaelReed,CarlLandwehr
WebMIXes: AsystemforanonymousandunobservableInternetaccess ........................101
OliverBerthold,HannesFederrath,StefanKo¨psell
PrivacyIncorporatedSoftwareAgent(PISA):Proposalforbuildinga
privacyguardianfortheelectronicage ......................................................117
JohnBorking
IdentityManagementBasedOnP3P ........................................................127
OliverBerthold,MaritKo¨hntopp
OnPseudonymizationofAuditDataforIntrusionDetection .................................147
JoachimBiskup,UlrichFlegel
ProtectionProfilesforRemailer Mixes ......................................................165
KaiRannenberg,GiovanniIachello

Preface
ThisworkshopaddressesthedesignandrealizationofanonymityservicesfortheInternetandothercommu-
nicationnetworks. Themaintopicsoftheworkshopare
AttacksonSystems,
(cid:15)
AnonymousPublishing,
(cid:15)
MixSystems,
(cid:15)
IdentityManagement,and
(cid:15)
Pseudonyms&Remailers.
(cid:15)
Anonymityandunobservabilityhavebecomea“hottopic”ontheInternet. Servicesthatprovideanonymous
andunobservable access to theInternetareuseful for electronic commerce applications (obviously with the
need for strong authenticity and integrity of data) as well as for services where the user wants to remain
anonymous(e.g. web-basedadvisoryservicesorconsultancy).
I would like to thank the other members of program committe John Borking, Marit Ko¨hntopp, Andreas
Pfitzmann, Avi Rubin, Adam Shostack, Michael Waidner, and Sonja Zwissler for their helpful hints, for
doing thereviews andfor theirpatience. A special thankis dedicated to Lila Finhill of ICSI for herhelpin
alladministrativeandfinancialconcerns,andChristianSchindelhauerforhissupportonLaTeX.
Berkeley,July2000 HannesFederrath

Traffic Analysis: Protocols, Attacks, Design Issues and Open
Problems
Jean-Franc¸oisRaymond
Zero-Knowledge Systems, Inc.
[email protected]
Abstract
Wepresentthetrafficanalysisproblemandexposethemostimportantprotocols,attacksanddesign
issues. Afterwards,weproposedirectionsforfurtherresearch.
As we are mostly interested in efficient and practical Internetbasedprotocols, most of the emphasis is
placed on mix based constructions. The presentation is informal in that no complex definitions and
proofs are presented, the aim being more to give a thorough introduction than to present deep new
insights.
1 Introduction
Privacy is becoming a critical issue on the Internet. Polls constantly remind us that users feel that one of
themost importantbarriers tousingtheInternetisthefearofhavingtheirprivacy violated. Unfortunately,
thisisn’tunjustifiedasmarketersandnationalsecurityagencieshavebeenveryaggressiveinmonitoringuser
activity1.
Two things can happen as a result of this lack of privacy: either the Internet’s popularity diminishes or, as
seemsmorelikely,theInternetbecomesthemostpervasivesurveillancesystemever. Theproblemstudiedin
this text isn’t a purely theoretic one, in fact some would argue that it is a crucial one to solve if the online
worldistocontinueexpandingandimproving. Inanycase,fromboththeoreticalandpracticalperspectives,
itcertainlydeservestoreceivemuchmoreattentionthanithasgottensofar.
1.1 Desirable Properties
Our goal is to protect users against traffic analysis. That is, we don’t want an adversary that can monitor
and/or compromise certain parts of the systems to be able to match a message sender with the recipient
(sender-recipient matchings).
A related problem is that of network unobservability which attempts to hide all communication patterns.
(how many, at what time and to whom/from whom messages are sent and received). Notice that network
unobservability impliestheineffectivenessoftrafficanalysis.
1Seehttp://www.freedom.netandhttp://www.inf.tu-dresden.de/˜hf2/anonforexamples.
7
Whereasmessageprivacy canbeobtainedusingencryption,it’smuchhardertoprotectsenderand/orrecip-
ient privacy; especially in large open networks. The number of different assumptions and settings is huge
whichmakesitdifficult todefineandreasonabouttheprobleminarigorousmanner.
As with manyconstructions in cryptography, there are efficiency, practicality/security tradeoffs to be made.
For example, if efficiency and practicality weren’t issues, we could broadcast messages in order to protect
recipientprivacy.
Noticethattheproblem definition isn’tentirely trivial. Wecan’tprovide ”perfect”privacy sincethenumber
ofpossible sendersandrecipients isbounded. So, forexample, ifthereareonlytwopartiesonthenetwork,
anattackerhavingaccesstothisinformationcantrivially determinewhoiscommunicatingwithwhom
:::
Thebest wecanhopeforistomakeallpossible sender-recipient matchingslook equally likely. Thatis, the
attacker’s view2’s statistical distribution should be independent from the actual sender-recipient matchings.
The protocol of subsection 2.2 has this strong property whereas those of subsection 2.3 usually don’t. Un-
fortunately, there are no satisfactory definitions/methods providing a solid framework in which to analyze
protocols that fall short of the optimal performance3 and we usually need to rely on more or less ad-hoc
arguments.
1.2 Overview
Aconciseliteraturereviewcanbefoundinsection2. Acomprehensivelistingofattacksagainstmix-networks
ispresentedinsection3. Designissuesrelatedtolargemixbasednetworksaregiveninsection4. Wepropose
directionsforfurtherresearchinsection5andconcludeinsection6.
2 Literature Review
Before delving more deeply into the problem, we briefly review some privacy protecting mechanisms. Al-
though the link between these and sender-recipient privacy can be tenuous in certain instances, we believe
thatsomeoftheideasusedinthesetechniquesmightbeuseful.
2.1 Related Problems
SecureMultiPartyComputations(SMPC)[14]: Agroupofusers,eachhavingaprivateinput,wantto
(cid:15) securely computeafunctionoftheirprivateinputs. Attheendoftheprotocol, allusersshouldknow
onlythevalueofthefunction. Thatis,eachuserwillnothavegainedanyinformationabouttheother
users’privateinputsapartfromwhatcanbededucedfromthefunction’svalue.
Oblivious RAM [22]: Code privacy can be protected by using a tamper resistant cryptographic pro-
(cid:15) cessor. Theprotocol is such than an outside party looking at thememory accesses (reads and writes)
can’t gain any information about what is being computedand how it is being computed. The code’s
privacyisprotectedwhichcouldbeusefultopreventreverseengineeringandsoftwarepiracy.
2Byview,wemeanalltheinformationavailabletotheattacker.
3i.e.protocolsinwhichtrafficanalysiscanhelpinobtainingsomenon-trivialinformationaboutsender-recipientmatchings.
8