– real-time deployable MIXes – different operators – different locations

Web MIXes: A system for anonymous and

unobservable Internet access

OliverBerthold 1

,HannesFederrath 2

, andStefanKöpsell 1

1

DresdenUniversityofTechnology,FakultätInformatik

{ob2, sk13}@inf.tu-dresden.de

2

InternationalComputerScienceInstitute,Berkeley

hannes@icsi.berkeley.edu

Abstract. We present the architecture,designissuesand functionsof

aMIX-basedsystemforanonymousandunobservablereal-timeInternet

access.Thissystem preventstracanalysisas wellasoodingattacks.

The core technologies include an adaptive, anonymous, time/volume-

slicedchannelmechanismandaticket-basedauthenticationmechanism.

Thesystemalsoprovidesaninterfacetoinformanonymoususersabout

theirlevelofanonymityandunobservability.

1 Introduction

Using Internet servicesnowadaysmeansleavingdigital traces.Anonymity and

unobservability on the Internet is a sheer illusion. On the other hand, most

peopleagreethatthereisasubstantialneedforanonymouscommunicationasa

fundamentalbuildingblockoftheinformationsociety.Theavailabilityofanony-

mouscommunicationis consideredaconstitutionalrightin manycountries,for

exampleforusein votingor counseling.

Wearedoingresearch onanonymityand unobservabilityin theInternet to

evaluatethefeasibilityandcostsofsuchsystemsand toexploreseveraldeploy-

mentopportunities within theInternet.Ourgoal isto explorethe foundations

andtoprovideasecureandanonymoustechnicalinfrastructurefortheInternet.

Systems that provide unobservability ensure that nobody, not even the

transportnetwork,is abletondoutwhocommunicateswithwhom.However,

thecommunicatingparties may knowandusuallyauthenticateeachother. Ex-

ample:Payingusersbrowsingapatentdatabase.

Systemsthat provideanonymityensurethatclientorserver(orboth)can

communicate without revealing identity. Example: Users browsing the World

Wide Web.

DuringthelastthreeyearswedevelopedseveralMIX-basedandproxy-based

anonymity services (for web surng and similar real-time services). Our aca-

demic interestis toshowthat anonymityandunobservabilitycanbeeciently

realized. The special objective is to develop a theoretical background for the

ecientimplementation ofanonymityservicesin theInternet. Wearebuilding

Springer-Verlag, Heidelberg 2001, 115-129.

provideasynchronous(likeSMTP)aswellasnearlysynchronousmodesofcom-

munication(likeHTTP).Thesystemshouldalsobeabletohandlevariouskinds

ofpackets.

Thewebsiteofourprojectishttp://www.inf.tu-dresden.de/~hf2/anon/.

Anonymity and unobservability are not new security goals. The following

systemsthatprovideanonymityservicesareknownbothinliteratureaswellas

in theInternet:(selection)

Anonymizer[1],

Crowds[2],

OnionRouting[3],

Freedom[4].

Theattackermodelsforthesesystemsaredierent,i.e.,thesesystemsprovide

dierentlevelsofanonymity.Acomparisonofthesesystemsisgivenin[5].

This paperis organized asfollows. In section2 we givean overviewof the

architecture of oursystem. Section 3 dealswith several attacksand their pre-

vention.Insection4,weexplainadditionaldesignissuesofourpracticalsystem

andtheirimplementation.

2 Components and Functionality

Basically,weuse

amodiedMixconceptwith

anadaptivechop-and-slicealgorithm(seebelow),

sendingofdummymessageswheneveranactiveclienthasnothingtosend,

aticket-basedauthenticationsystemthatmakesoodingattacksimpossible

orveryexpensiveand

a feedback system that gives the user information on his current level of

protection.

TheMIXconcept[6]aswellastheadaptivechop-and-slicealgorithmwillbe

describedinthissection.Theticket-basedauthenticationprocedureisexplained

in section3.1 andthefeedbackmechanismin section3.1.

The complete system consists of three logical parts: the JAP (Java Anon

Proxy) on the client-side, the MIXes and the cache-proxyon the server-side.

These partsare concatenatedinto achain, buildingtheanonymous tunnel.All

networktractobeanonymizedissentthroughthistunnel.Inprinciple,asingle

user remainsaonymous since the tunnel has manyentrances(users), but only

oneexit.Everyusercanpossiblycausethetrac observedatthetunnel-exit.

JAP. JAPisconnectedtotherstMIXviaInternet.Ideally,theMIXesshould

beconnected viaseparate high-speed connectionsdue to performance reasons.

However,thiswouldbeverycomplexandexpensive,henceourMIXesuseonly

Browser

Cascade of MIXes:

– real-time deployable MIXes – different operators – different locations

– cascade: fixed sequence of servers – secure against traffic analysis

– for better performance: more than one cascade

CA

Web Server

Certification Authority:

– independent of Web Mixes System – issues certificates of public keys

Information Service:

– traffic situation – anonymity level – warnings Java Anon Proxy:

– client software – platform independent – local proxy – constant dummy traffic – adaptive time-slices – tickets against flooding

unobservable data flow

redundant Info Service requests

Info Service Client 1

. . . .

. .

Browser

Client n

Anonymity group:

Each client is unobservable in the group of n clients

JAP ^Cache _Proxy

Server Server

JAP

MIX MIX

Info Server

MIX

Info Server

Secure reliable update and replication of Info Servers

Fig.1.Architectureofourservice

TheJAPisaprogramwhichisinstalledlocallyoneachuser'scomputer.All

networktractobeanonymizedgoesthroughthissoftware.TheJAPtransforms

thedatasothat itcanbeanonymizedbytheMIXes.

FollowingfunctionsareprovidedbyJAP:

Registrationof theusertotheMIXes,

Periodicalset-upoftime-slice-channels(generatingandsendingofasymmet-

ricallyencryptedchannel-building messages),

Sendingandreceivingdataviathechannels.Dummymessages(forinstance,

randombitsorencryptedzerobits)aregeneratedifthereisnothingtosend.

Listening for requests coming from the browser or other programs of the

clientthatliketocommunicate inananonymousway,

Filteringofcontentthatwouldbedangerousfortheanonymity,e.g.,cookies

andactivecontentslikeJavaScript,ActiveXandotherembeddedobjects,

TransformingdataintotheMIX-formatandsendingthroughananonymous

channel,

ReceivingdatafromtheactiveMIX-channelandforwardingittotheorigi-

natingapplication,

Periodicalutilizationofaninfo-service,sothattheusergetsfeedbackabout

MIXes. Ourbasicconceptsareverysimilartoothersystemsbasedontheideaof

MIXes[6].AMIXscramblestheorderofdatastreamsandchangestheircoding

usingcryptographytomaketraccorrelationattacksdicult.

TheMIXes are simple computers connected viathe Internet. Theyform a

logicalchain,calledMIX-cascade.TherstMIXreceivesdatasentbytheJAPs.

AMIXmakessomecryptographictransformations(stripsalayerofencryption,

preventsreplay attacks,reordersmessagesandcreates abatchthat consists of

allmessages)andsendsthedatatothenextMIX.

Thelast MIXsendsthedatatothecache-proxy.

Bymeansofconstantdummytrac,allsenderssendmessagesatanytimeto

createthesameanonymitygroup.Ifnecessary,randomdataisgeneratedwhich

cannotbedistinguishedfromgenuineencryptedtrac.Dummytrachastobe

sentbetweentheendpointsofacommunicationrelation.Dummytracbetween

MIXesonlyisnotsucienttopreventtracanalysis.

Ourattackermay

control upto n 1MIXes ifn is thetotal numberof MIXes in the MIX-

cascade,

controlthecache-proxyand knowsthereceiverandcontentof allmessages

becausealltracgoes(mostlyunencrypted)throughthecache-proxytothe

Internet,

block every message, generate his own messages and modify all messages.

These active attacks will be recognized and consequently prevented by a

ticket-basedauthenticationsystemexplainedinsection3.1.

Cache-proxy. The cache-proxysends the datato the Internet and receivesthe

answersfrom theservers(e.g., web servers). The answerswill be sent back to

theuserviatheMIXes(in reverseorder).AsJAPdoes,thecache-proxyhasto

senddummytracaswell.

Once atime-slice-channel is established,it cantransport a certainnumber

ofbytes.Thereafter,thechannelisreleasedautomatically.Ifmoredataneedsto

betransmittedsequentialtime-sliceconnectionsmustbeestablished.Seesection

3.1formoreinformation.

Anotherfunctionality of both JAPand cache-proxyaectsthe HTTPpro-

tocol.Asfarassecurityandperformanceareconcerned,itmakessensethatthe

cache-proxyautomaticallyloadseveryobjectembeddedintoaHTML-page,e.g.,

links to embedded images. Thecache-proxycanthensend thewhole page (in-

cludingtheembeddedobjects)atthesametimethroughtheanonymouschannel.

ThisideawasproposedthersttimebytheCrowdsproject[2].

In order to realize this idea, both cache-proxy and JAP must provide the

followingfunctions:

Cache-proxyscansthedatareceivedfromawebserverforembeddedobjects.

Cache-proxyautomatically requests these objects and sendsthem through

theanonymous channel tothe user'sJAP. Inaddition, cache-proxyshould

provide traditional caching functionality in order to reduce thenumber of

JAPrepliestotherequestsforembeddedobjectsbysendingdataalreadyre-

ceivedfromthecache-proxy.ThenumberofrequestssentfromJAPthrough

theanonymouschannelistherebydramaticallyreduced.

Info-service. Info-service provides data for maintenance and operation of the

anonymousnetwork.Itprovides

addressesandpublickeysoftheMIXes,

informationonthetracsituation,

theavailabilityofMIXes,

dataabouttheachievablelevelofanonymity,i.e.,thenumberofactiveusers

intheanonymousnetwork.

A screenshot of the graphical user-interface of the info-service is given in

section4.2.

3 Attacks and Solutions

Forreal-time communication,weadditionallydevelopedthefollowingconcepts

bothto maketracanalysisharderandtoincreasetheeciency.

Tracanalysismeansthatanattackerwhoisabletocontrolthecache-proxy,

can linkaparticularrequesttothesameuser.Everymessagewaspossiblysent

by adierent groupof users, sothat theattackercan usethis information to

intersecttheanonymitygroup.

SeveralattacksexistagainstthebasicconceptofMIXes.Theattacker'sgoal

istoobserveusersortostoptheservice(Denial-of-Serviceattack,DoS-attack).

Wedescribeconceptswhichpreventtheseattacksormakethemverydicult

andeventuallyidentifytheattacker.

3.1 Solutions against observation

Therearetwosortsofattacks:passiveandactiveattacks.

Apassiveattackercanonly eavesdropon communication links,but cannot

modifyanynetwork trac.

It is impossible to detect passive attacks. The only solution is to prevent

them.

Dummy messages Dummy messages are sent from the starting point (i.e.,

client)ofacommunicationintotheMIXnetworktomaketracanalysisharder.

Sendingdummymessagesguaranteesthatalluserssendthesameamountof

dataduringeachtimeslice.Sincealltrac(includingthedummies)isencrypted,

noone,evenanattacker,whoobservesallnetwork cablescanknowwhichuser

sendsdummiesandwhichonesends realinformation.

If the groupof users does not change (especially when nobody leaves the

group),apassiveattackercannotsplit thegroup.

Thusitisnecessarythateachuseroperatesatleastonechannelatalltimes.

periodicallysendchannel-buildingmessages,

sendrealdataordummytraconhischannels,

receivedata sentbythecache-proxy.

EachMIXhastosenddummymessagesbacktotheuseriftheuserdoesnot

receiverealdata.Thisensuresthateachuserreceivesthesameamountofdata

during each time slice. Since at least the trustworthy (i.e., unattacked) MIX

willsendthesedummies,itsuccessfullyavoidstheseattacks,supposingthatany

otherMIX(or thecacheproxy)doesnotsenddummies.

Adaptive chop-and-slice algorithm Large messages (and streaming data)

are chopped into short pieces of aspecic constantlength, called slice. Each

slices istransmittedthroughananonymousMIXchannel.Inaddition, active

users without an active communication request send dummy messages. Thus

nobodyknowsthestartingtime and durationofacommunication,becauseall

active users start and end their communication at the sametime. Otherwise,

an observer could determine where and when the anonymous channel starts

and endsand couldnd outwhois communicatingwith whom. Depending on

thetracsituation,wemodifythethroughputanddurationoftheanonymous

channel.Theconceptofchoppinglongcommunicationsintosliceswasintroduced

thersttimein[8].

Weuseamodiedversionwithanadaptivedurationorthroughput.Oncea

time-slice-channelisestablished,itcantransportacertainnumberofbytesand

is afterwards releasedautomatically. If an anonymous connection takes longer

thanonetime-slice,itwillbecomposedofanumberoftime-slices.Inthiscase,

JAP provides ID numbers, which cache-proxy uses to refer to an anonymous

connection(SlicenumberSl,seeFig.2).

Incomparison to sending each MIX message separately, a MIX channel is

moreecient,becauseit's notnecessarytodecrypt allthese messagesusinga

slowasymmetricalgorithm. SinceaMIX mustcollectallmessagesoftheusers

beforesendingthemtothenextone,thedelaytimeineveryMIXisproportional

tothelengthofmessages.

Toestablishanewslice,auser sends(togetherwith allother users)acon-

ventionalMIXmessagethroughtheMIXes.Thismessagecontainsasymmetric

keyforeachMIX. Thiskeywill beusedto decryptorencryptdata, which will

besentlater throughthe channel.Thetime whenthechannelstartsisdened

by the stateof the whole system. Normally, it startswhen the last slice ends.

Thesliceendswhenacommittednumberofbyteshavebeentransferred.Incase

of an error, especially if an attacker has manipulated some data, the channel

is supposed to stopimmediately. Otherwise, theattackercanpossibly observe

whichchannelisdamagedandistherebyabletocorrelatesenderandreceiver.

Ticket-based authentication system Averydicultproblemoccurs when

anactiveattackeroodstheanonymityservicewithmessagesinordertouncover

{Get Server/Page.html}

response Get Server/Page.html

{Response NIL, wait, Sl, Padding}

{Response Block[i], wait, Sl, Padding}

{Response Block[i], EOF, Sl, Padding}

{Get C-Proxy, Sl}

END

JAP Cache

proxy

MIX MIX MIX

Create and store Sl IF (no answer from Server yet) AND (no timeout)) THEN send

IF not EOF send

ELSE send

Server

IF not EOF send

ELSE send

Fig.2.TimeSliceProtocol

Webelievethatwehavefoundanewconcepttosuppressoodingofmessages

bothfrom outsiders(normalusers)andinsiders(MIXes).

Firstlywelimiteithertheavailablebandwidthorthenumberofconcurrently

usedtimeslices foreachuser.

Secondlyeveryuserhastoshowthat heisallowedtousethesystematthe

respective time slice by providing aticket only valid for acertain slice. To

protecttheidentityoftheuser,theticketisablindedsignature[7]issuedbythe

anonymous communication system. More precisely, each MIX issues a limited

numberoftickets foreachchannelanduser.

Detaileddescription of procedure:

Step1: The user established a connection to a MIX. This connection guar-

antees condentiality and integrity and authenticates both MIX and

user(i.e.,itispossibletouseSSL).Theuserownsadigitalcerticate

and authenticates himself to the MIX. The MIX checksthat he gets

this certicate for therst time(so it is impossibleto get morethan

oneticketbyreconnectingtotheMIX).Thecerticateauthorityguar-

antees that each user getsone and only one certicate orit must be

recognizablethatdierentcerticatesbelongtothesameuser(i.e.,by

Step2: Now the user sends a blinded message to the MIX, which the MIX

shouldsign.Thismessageconsistsofakeyforasymmetriccipherand

somebitsformingaredundancy.

Step3: The MIX signsthe message using a special key(pair), which is only

valid foracertaintime slice.WeareusingRSA andforeachnewkey

pair (foreach time slice) weuse thesame modulus n,but wechange

thepublicandprivateexponents.

Step4: Theuserunblindsthemessageandveriesthesignature.Nowheowns

avalidticket,whichisnotlinkabletohim.

Step5: Theuserrepeatssteps1-4foreachMIX.

Step6: Theusergeneratesthemessage(channel-buildingmessageordatames-

sage). Assuming that there are k MIXes. The user concatenates the

ticket thathe getsfromMIX kwith thedatahewantstosend. Then

he encryptsthemessage.Heusesthepublickeyof MIXk inorder to

encrypt the rst partof the message. Forthe rest of themessage he

uses the symmetrickeyincluded in the ticket.Next, he concatenates

theticketissuedbyMIXk 1withthegeneratedmessageforMIXk.

HeencryptsthemessageinthesamewayusingthepublickeyofMIX

k 1andsoforthuntilheencryptstheticket issuedbytherstMIX.

Step7: The user sends the message(generated in step 6) through the MIX-

cascade.

Ifthe MIX uses the sameprime numbers pand q (and therefore thesame

modulus n) for theasymmetric encryption/decryptionof the message and for

signing/checkingthe tickets,there will beno additionaloverhead forverifying

thetickets.

Theticketexactlytsintherst(asymmetricencrypted)partofthemessage

(step 6). TheMIX decrypts the messageand veriestheticket in one stepby

decrypting the message using the product of it is secret decryption key and

it is public signature test key. Furthermore, the MIX extracts the symmetric

key, which will be used for the channel and veries theticket by checkingthe

redundancy.

As we already explained, a ticket only consists of a symmetric key and a

redundancy. For an acceptable level of security, about 200bits are needed to

store aticket. Since weuse RSA,the size of theticket would increaseat least

upto1024bits.

Eachtickethasunused spaceofabout800bits. Itis possibleto storeother

data in this free space, but it must be known when the ticket is requested.

This is actually not a disadvantage, since the ticket is used for the channel-

building message. The free space of each ticket could be used to store a part

ofthemessage,whichisaddressedtothenextMIX. Thus thechannel-building

messagewould become smaller,becauseweonly need200bits perMixinstead

of1024(exceptforthelast MIX).

Inordertousethisoptimization,wehavetochangetheprocedureasfollows:

Steps1-4aremodiedsothattheticketswillberequestedsequentiallystart-

symmetrickey, computestheredundancy andllsthefree spacewith therst

bytesofthealreadygeneratedmessage.

Sinceweknowthewholeremainingmessageatthetimewegenerateaticket,

wecan useangerprintofthismessageasredundancy.TheMIXcancalculate

the ngerprint in step 7 and thus verify the integrity of the whole received

message.

Step1-4(andperhapsstep6)canbedoneparallel,sothatwecanonlysend

one largemessage (requesting manytickets) instead of many short ones. This

willincreasetheeciency,especiallytheauthentication(step 1)hastobedone

onlyones.

Iftheduration ofonetime sliceislongenough,the overhead forthe ticket

methodwon'tbeveryhigh,sincewe'llneedonlyoneticketperMIXandchannel.

Themostexpensivefactoristhattheusermustdirectlygettheticketsfromeach

mix throughanencryptedchannel.

Usingtickets is usefulin orderto add the dimensionof aprepaid payment

systemfortheanonymitysystem,too.

However,thishasnotyetbeenimplemented.

Measurementofanonymitylevel Iftheattackerobservesallnetworktrac,

heisabletoreducethenumberofpossiblesenders(i.e.,thenumberofmembers

within theanonymitygroup) ofamessage.Atthe extreme,he may be ableto

identify the user who sends the message. This is called intersection attack.

Theintersectionattack canonlybepreventedifthe anonymitygroupremains

constant.

Ifthegroupofactiveusershadchanged,thelinkedmessagesmusthavebeen

sentbyauser,whoismemberoftheintersectionofallgroupsofusers.

Dummytrac makesintersectionattacksmoredicult,but doesnotcom-

pletelypreventthem.Ifallactiveuserspermanentlysenddummymessages,each

receivedmessagecouldpossiblycomefrom anyuser.

However,uptonow,itisnotclearhowtopreventsuchanattack,especially

ifweconsideraglobalobserver.

Theanonymityleveldependsonthenumberofactiveuserswithinthesystem.

Weneedamechanismoraheuristicthatinformstheuserofhislevelofprotection

whenherequestscontentsfromtheInternet.

Inourdesignweinformeachuserofhiscurrentlevelofanonymity.Theuser

candecidetorecedehiscommunicationrelationiftheanonymitylevelbecomes

lessthanauser-denedthreshold,i.e.,thenumberofactiveusersinthesystem.

Webelievethatitisimportantfortheusertobeawareofhisdegreeofprivacy.

Thismakesthesystemmorereliableandtrustworthyfortheuser.

EachMIXhastopublishperiodically

1. thenumberofactiveusersand

2. thelogouttimeofeach userwholeavesthegroup.

Theclient(JAP)receivesthisinformationviatheinfo-serviceandcomputes

computes how many users were active from this time on, using the published

logouttimes.Theseusersrepresenttheanonymitygroup,becauseonlytheyare

possiblesendersofallmessages.

Whenanewconnectionis established,JAP storesthetime and numberof

activeusers. Everytime the MIXespublishes the logouttimes, JAP decreases

the size of theanonymitygroupfor each detectedrelevant logout.A logout is

relevant ifthe corresponding logoutwasearlier than the stored starting time.

Theuserwillbealertediftheanonymitygroupbecomestoosmall.

Theinformationaboutthenumberofactiveusersandlogouttimesaredig-

itally signed by each MIX. So it is impossible for the attacker to manipulate

themin ordertofakeabiggeranonymitygroup.

Theclientshould alwaysassumethatthelowestpublishednumberofactive

usersandthehighestnumberoflogoutsistruein ordertopreventattacksfrom

aMIXitself.

Since it is impossible to prevent the intersection attack, we can only give

advicetousersonhowtomitigatetheeect ofintersectionattacks:Thesuccess

ofanattackcanbefurtherreducedbyavoidinglinkableeventssuchasCookies,

requestofpersonalwebpagesorusageofpseudonymsinchatservicesmorethan

once.

Ifanattackeralsousesactiveattacks,hecanincreasehischanceto identify

asender.Inorder todo so,hetries toexcludeparticular usersfromthegroup

ofpossiblesendersby

blockingsomemessagesordestroyinganetwork cable,

sendingmessages,whichappearto besentbyotherusers,and

manipulatingmessages.

However,itispossibletodetectactiveattacks.

3.2 Protection against DoS-Attacks

Insection3.1wedescribedaprocedurefordetectingactiveattacks,butwedid

notdiscusswhattodoifwedetectedsuchone.Ifanattackisignoredoraected

messageissimplydeleted,theattackerhaspartlyreachedhisgoal.

One solution could be to delete all aected messagesor to close all open

channels. As aconsequence,it would beveryeasy to start aDoS-attack: The

attackeronlyhastosendonebrokenmessageinordertoimpairthewholeMIX-

cascade.Iftheattackerisunabletobreaktheanonymity,hemaysimplyprevent

theusageoftheMIX-cascade.

AbettersolutionistogiveeachhonestuserorMIXthechancetoprovethat

he/it hassentcorrectmessagesonly.

Ifanerroroccurs,eachMIX willhavetoprovethat ithasworkedcorrectly.

An attacking MIX cannot do so and is consequently identied. If all MIXes

workedcorrectly,theuser,whohassentthebrokenmessageistheattacker.

Inorderto provethecorrectnessof each participant(includingtheMIXes)

Detaileddescription of procedure:

a. IfaMIXcannotverifythesignature,itrequeststheoutputoftheprevious

MIX again. If it does not get correct data after a certain period of time

(timeout),itwillsignalasignature-error.Inthiscase,itisnotclearwhothe

attackeris.Possiblecandidatesare:

theMIXitself,

thepreviousMIX,

thenetwork betweentheseMIXes.

b. IfMIXidetectsanerror,itpublishesthewholedecryptedmessage(including

theerror).Noweverybodyisabletoencryptthatmessagebyusingthepublic

keyoftheMIX.Iftheresultisidenticalwiththereceivedmessage,theMIX

has provedthat it has decrypted the received message correctly, but that

messageneverthelesscontainsanerror.Theerrormusthaveoccurredat or

causedbythepreviousMIX.

c. AllpreceedingMIXesi x(x=1:::i 1)areobligedtocontributetothe

followinguncovering-procedureuntiltheerrorhasbeenfound:

1. MIX i x has to provide the input-output correlation of the certain

messageandeveryonecanverifythattheMIXhasdecryptedthemessage

correctly(seeb.).

2. Iftheerrorisfound,theuncovering-procedurehastostopimmediately

and theresults haveto bepublished. That meansthat MIXesi x+

1:::i 1areattackers.

3. Ifthecheckwassuccessful,theMIXhastopublishthedecryptedmessage

(likeMIXi).

d. Ifall MIXesprove that theyhaveworkedcorrectly, onlythe senderof the

broken message can be the attacker. He is the only one who was able to

generateamessage,whichcontainsanerrorthatwouldbedetectedbyMIX

i.

HencefaultyMIXescanbeexcludedunlesstheyhavebeenproventhatwork-

ingcorrectly.A user,whoproduceserrorscanalso beexcludedfrom thegroup

ofusers.

AusercanonlycarrythroughaDoS-attackforalongtimeifheperiodically

changeshis identity.Thisispossibleifheworkstogetherwithacorrupt certi-

cateauthority.Afteraperiodoftime,noonewilltrustthiscerticateauthority

anylonger.

Nevertheless, there still remains adisadvantage:The trustworthyMIX has

to uncoverhis decryption.If allother MIXes areattackersandwork together,

theycoulddeterminethesenderandreceiverofamessage.However,theattacker

loses oneMIXeachtimetheuncovering-procedurewillbeperformed.

IfatleasttwoMIXesaretrustworthy,theuncovering-procedurewon'tbreak

theanonymity:

1. A user has cheated: There is no need to protectthis user, because the

2. A MIX has cheated: The rst trustworthy MIX of the cascade, which

getsafaultymessage,startstheuncovering-procedure.Thisprocedure con-

tinues until the attacking MIX is reached. If the second trustworthy MIX

is before the attacking MIX, the attacker will not be able to detect the

senderof amessage,becausethetrustworthy MIX will notperform anin-

validuncovering-procedure.

IfthesecondtrustworthyMIXisbehind,thereceiverofthemessageisnotde-

tectable.Theattackermaygetthecorrectmessagethroughtheuncovering-

procedure,butthesecondtrustworthyMIXprotectsthecorrelationbetween

senderanreceiver.

Thedescribeduncovering-procedureis usefulfor theasymmetricencrypted

MIX messages aswell as to verify the transmissions of the channels. On each

channel, aredundancy for each mix (i.e., amessagedigest of thedata already

sent)issent.

Additionally, each MIX has to storeall transmitted data and the channel-

building-messages.Ifanerroroccurs,itwillbeabletoprovethatithasdecrypted

the data of the channel correctly by using the symmetric keyincluded in the

correspondingchannel-buildingmessage.

Onespecic feature of the channel is that the data will reach the receiver

in verysmall pieces. If thevericationof the channel isdone later, theattack

mayhavealreadybeensuccessful. Thisis possible,evenif allother MIXesare

trustworthy.But in this casetheattackerwill lose at leastoneattacking MIX

everytime he attacksa channel. This is notacceptable evenfor a verystrong

attacker, so that the anonymity of a normal user will not be reduced, if the

uncovering-procedureisperformed.

4 Other Design Issues

4.1 General

Themainfocusofourdevelopmentprocessistheusabilityofthewholesystem.

This includes two aspects. Firstly we try to make the handling of the Client

(JAP) aseasyaspossible,sothat manypeopleareableto useit.This includes

theinstallationandcongurationaswellasthedesignoftheuserinterface.

Thesecondaspectofusabilitycoverstheperformance,especiallythethrough-

putand thedelaytimeoftheanonymousnetworkaccess.

4.2 The Client (JAP)

Thedevelopmentisbasedonthefollowingrequirements:

Theclientmustbeexecutableondierenthardware/operatingsystems,in-

cludingatleastWindows(95,98,NT,2000),Linux,AppleMacintosh.

Theclient(JAP) must beeasyto installbytheuser.It should bepossible

Thecongurationmustbeaseasyaspossible.Evenuserswithoutextensive

knowledge in security and cryptography should be able to congure the

system.

Usersmust be protectedfrom thinking tobeanonymousiftheyuse amis-

conguredclient.

Aanonymousnetworkaccess shouldbepossible,even iftheuserisbehind

arewallorproxy.

Theuserinterfacemustshowandexplaintheuser'scurrentlevelofanony-

mity.

It must be easy to switch between anonymous ornon-anonymous network

access.

Atthemoment,JAVAisusedastheprogramminglanguage.That'sbecause

of the JAVA-capability: Write once, run anywhere. Later it should be possi-

ble to develop special versions for each operating system. These versions will

provide a better performance and lesser resources will be needed. A suitable

integrationinto thelook&feelofthetargetoperatingsystemwillincreasethe

user-friendliness.

FortheexecutionoftheJAPitisnecessarytohaveJavaRuntimeEnviron-

mentVersion1.1.8orequivalent,theGUI-librarySwing (Version1.1.1),anda

cryptographiclibrary,presently logi-crypt,installed. These librariesarecom-

pletelywritten in JAVAso that wecan easilydistribute them with ourclient.

All otherlesneededfortheJAP(theJAVAbytecode,pictures,help lesand

soon)are includedin onesinglearchive(.jar-le).This le mustbecopied to

thetargetsystemandcandirectlybeexecuted.

Inordertomakethecongurationprocesseasy,itshouldbepossibletodown-

loadthewhole congurationdataviaInternet.Of course,wehavetodevelopa

secureinfrastructureforthis.

Furthermore,manyusersgainaccesstotheInternetviaanISP.Theprovider

canforcethesurfertouseaspecialweb-proxythatdoesnotallowdirectInternet

connections.Inordertogivesuchpeoplethechancetosurfanonymously,itmust

bepossibletoconnecttotherstMIXviatheweb-proxyoftheISP.Therefore,

alldatamustbeembeddedintotheHTTP-Protocol.

Fig.3showstheAnonym-O-Meter,ourrstattempttogivetheuserfeed-

backabouthiscurrentlevelofprotection.Thisisanareaofourfutureresearch

aswell.

4.3 The MIX-Servers

AmainpointconcerningthedevelopmentoftheMIXesistheperformance,since

thishasagreatinuenceontheusabilityofthewholesystem.Nevertheless,we

alsofocusoneasyadministrationandmaintenance.IncontrasttotheJAP-user,

administratorshaveadeeperknowledgeincomputers,andpossiblyin security.

OurMIXes areimplemented using C++asprogramminglanguage. Wedo

Fig.3.Screenshot

is available on many operatingsystems. Dierences result from using the sys-

tem functions like network input/output or from programming the graphical

user interface. Since MIXes are console applications without any GUI, this is

unproblematic.We onlyneedafewsystemcalls.Themain tasksof MIXesare

cryptographicandalgorithmicoperations.InordertoporttheMIXesto anew

target operatingsystem, only a few modules/functions must be adapted.Our

goalistosupport afewimportantandcapableoperatingsystems(forinstance

Linux,Solaris,AIXandWindowsNT).

Theadministration is realizedvia aspecial network interface implemented

by theMIXes. Thus, it is possibleto separate the MIXesand the administra-

tion tools physically and logically.Presently, we are thinking about aGUI for

administrationpurposeswrittenin JAVA.

Acknowledgements

We would like to thank Prashant Agarwal, Christoph Federrath, Mary Weiss

References

1. TheAnonymizer.http://www.anonymizer.com

2. MichaelK.Reiter,AvielD.Rubin:Crowds:AnonymityforWebTransactions.ACM

TransactionsonInformationandSystemSecurity1/1, November1998,66-92.

3. OnionRouting.http://www.onion-routing.net

4. TheFreedomNetwork.http://www.freedom.net

5. OliverBerthold,HannesFederrath,MaritKöhntopp:ProjectAnonymityandUn-

observabilityintheInternet.WorkshoponFreedomandPrivacybyDesign/Con-

ferenceonFreedomandPrivacy2000,Toronto/Canada,April4-7,2000,57-65.

6. David Chaum: Untraceable Electronic Mail, Return Addresses, and Digital

Pseudonyms.CommunicationoftheACM24/2(1981)84-88.

7. DavidChaum:BlindSignatureSystem.Crypto'83,PlenumPress,NewYork1984,

153.

8. AndreasPtzmann,BirgitPtzmann,MichaelWaidner:ISDN-MIXesUntraceable

CommunicationwithVerySmallBandwidthOverhead.7thIFIPInternationalCon-

ferenceonInformationSecurity(IFIP/Sec'91),Elsevier,Amsterdam1991,245-258.