Two Cents for Strong Anonymity: The Anonymous Post-office Protocol

20 Pages·2016·1.57 MB·English

ProceedingsonPrivacyEnhancingTechnologies2016;2016(2):1–20
Nethanel Gelernter, Amir Herzberg, and Hemi Leibowitz
Two Cents for Strong Anonymity:
The Anonymous Post-office Protocol
Abstract:WeintroducetheAnonymousPost-officePro- tency; to achieve this, Tor design prefers reducing la-
tocol (AnonPoP), a practical strongly-anonymous mes- tencytoimprovinganonymity,andisvulnerabletoglob-
saging system. AnonPoP design combines effectively allyeavesdroppingadversaries.Severalworksshowthat
known techniques such as (synchronous) mix-cascade Torisvulnerableeventoweakerattackers,e.g.,off-path
and constant sending rate, with several new tech- attackers [28] and malicious servers/clients [3] [10].
niques including request-pool, bad-server isolation and The popularity of Tor indicates that it provides
per-epoch mailboxes. AnonPoP offers strong anonymity valuableservicetomanyusersandscenarios,despiteits
against strong, globally eavesdropping adversaries, that limitedguaranteesforanonymity(anditsnon-negligible
may also control multiple AnonPoP’s servers, even all- overhead). However, there are also many scenarios and
but-one servers in a mix-cascade. Significantly, Anon- users that require stronger anonymity properties, even
PoP’s anonymity holds even when clients may occa- at the cost of somewhat higher latency and overhead.
sionally disconnect; this is essential to support mobile Several works proposed protocols for stronger
clients. anonymity guarantees, as compared to Tor. However,
AnonPoP is affordable, with monthly costs of 2¢ per existingresearchonstronganonymityismostlyimprac-
client, and efficient with respect to latency, communi- tical. Indeed, many seem to believe that it is infeasible
cation,andenergy,makingitsuitableformobileclients. toensurestronganonymitypropertiesinapracticalsys-
We developed an API that allows other applications tem for many users, with acceptable overhead and effi-
to use AnonPoP for adding strong anonymity. We vali- ciency. We show that it is feasible to have practical, ef-
datedAnonPoP’sfunctionality,reliability,efficiencyand ficient system providing strong anonymity at low costs,
usability by experiments using web-based and mobile supporting large number of users.
applications used in ‘double-blinded’ usability study, Another limitation of Tor is that it provides a com-
cloud-based deployment and simulations. munication channel, but not a complete messaging sys-
tem. A complete messaging system should also provide
Keywords: Anonymity, Mixnets, Privacy, Annonymous
‘mailbox’ facilities to keep messages until users pick
communication, Tor
them up; this is also required to prevent detection of
DOIEditortoenterDOI apairofuserswhichfrequentlycommunicatewitheach
Received..;revised..;accepted... other and may get disconnected. A naive mailbox solu-
tion, where Tor is used to communicate with a mailbox
server,wouldallowtheservertode-anonymizeusersby
1 Introduction exploitingTor’sweaknesses,e.g.,eavesdroppingonpar-
ticular(suspect)user,andcorrelatingbetweenmessages
sent/receivedbythisuser,andmessagesreceivedtothis
There have been many efforts to develop, analyze, de-
mailbox or sent from this mailbox.
ploy and use anonymous communication protocols and
In summary, there is large interest in anonymity,
systems.Inparticular,theToranonymousnetwork[23]
andTorofferssomelevelofanonymouscommunication;
is widely used. However, Tor focuses on minimizing la-
however, neither Tor nor any other practical (existing
orproposed)systemallowsstrongly-anonymousmessag-
ing. This is disappointing; strong anonymity messag-
ing is both necessary and feasible. Messaging is used
Nethanel Gelernter:Dept.ofComputerScience,
CollegeofManagementAcademicStudies,E-mail: more and more for business and personal communica-
[email protected] tion,andanonymityisoftenrequired-forreasonsrang-
Amir Herzberg:Dept.ofComputerScience,BarIlanUni- ingfromwhistle-blowingtoconsultingonsexualharass-
versity,E-mail:[email protected]
ment. And, as we show, strongly-anonymous messaging
Hemi Leibowitz:Dept.ofComputerScience,BarIlanUni-
versity,E-mail:[email protected] is feasible, since the volume of (text) messages is not
TwoCentsforStrongAnonymity:TheAnonymousPost-officeProtocol 2
verylarge,andreasonabledelaysareacceptable.Hence, eryotherproposedprotocolsforanonymousmessaging,
it is frustrating that such system is not yet operative. withacceptableoverheadandextremelylowyearlycost
Inthispaper,wepresenttheAnonymousPost-office (<0.25$ per client). Furthermore, AnonPoP is the first
Protocol (AnonPoP), a practical anonymous messag- protocol that was designed and shown to be suitable
ing system, designed to ensure strong anonymity, even also for mobile devices.
against strong attackers. We present the design, its ra- Beyondthat,thispapermakesthefollowingcontri-
tionale and its anonymity properties, and discuss prac- butions:
tical deployment aspects, including: - The request-pool technique, allowing ‘masking’ of pe-
1. Implementation and evaluation in real world envi- riods when a client is disconnected.
ronment. - Per-epoch mailboxes, limiting the exposure due to
2. Operating costs in cloud environment. client disconnections and due to active tagging attacks.
3. Adjustmenttomobiledevices,withanemphasison -Thebad-serverisolationmechanism,allowingisolation
user experience and energy consumption. of corrupt server (mix or PO), involved in aggressive
(non-stealthy)taggingattacks.Othertechniques,times-
Anonymitylovescompany[22]:hence,thegoalofAnon-
tamps and de-duplication, are used to prevent and/or
PoP is to provide strong anonymity with superb func-
detect tagging attacks.
tionality,usability,reliability,efficiencyandlow-cost,as
- We fine-tune AnonPoP to allow its use in mobile de-
necessary to attract many users, and with the scala-
vices, including energy-savings considerations. We con-
bility required to support millions of users. In partic-
ducted double-blinded user-sensitivity experiment to
ular, AnonPoP uses efficient cryptographic primitives
validate acceptable energy use.
and has acceptable energy consumption, making it ap-
-Anopen-sourceprototypeofAnonPoP,includingAPI
propriateforuseonmobiledevices.Furthermore,Anon-
for applications, and an Android messaging application
PoP is the only proposed anonymous messaging proto-
that uses this API.
col to support client disconnections, a feature which is
essential to support mobile clients.
TomeasureandconfirmAnonPoP’slowoperatingcosts,
Paper Layout and Organization
we implemented and installed AnonPoP’s servers in
In section 2, we start with an overview of AnonPoP
the cloud, and tested it on hundreds of thousands of
architecture and main building blocks. We then define
clients, communicating anonymously with each other
andexplaintheadversarymodelandallanonymityno-
using AnonPoP. We found that the cost of supporting
tions and properties achieved by AnonPoP in section
such a large amount of clients is less than a quarter per
3. Sections 4-6 will explain how AnonPoP design and
user, per year, or two cents per month.
mechanisms handle attacks against wide range of at-
We provide an API for messaging applications to
tackerswithdifferentresourcesandcapabilities.Section
easily add an option for strong anonymity using Anon-
7 will detail a ‘double-blinded’ usability study, show-
PoP.WiththisAPI,clientsofdifferentapplicationscan
ing that AnonPoP is suitable for mobile devices. Sec-
formonelargeanonymityset.Forexample,weusedthe
tion 8 will present a cloud based evaluations conducted
API to rapidly develop an anonymous Eliza [49] client,
under‘real-world’conditions,demonstratingthefeasibil-
demonstratingtheuseofanonymousmessagingforsen-
ityofAnonPoPanddiscussingoperatingcosts,andthe
sitive consulting services.
AnonPoP API. We conclude by surveying related work
Readers are encouraged to try out AnonPoP using
in comparison to AnonPoP in section 9.
a mobile application, web-interface and the API [1], to
experience the efficiency, acceptable overhead and us-
ability.
2 Architecture and Concepts
Contributions ThegoalofAnonPoPistosupportanonymousexchange
Our main contribution is the design, development and ofmessagesbetweenclients;messagesarepackedatthe
evaluation of strongly-anonymous messaging protocol, clientsintofixed-sizeenvelopes,andsentviaAnonPoP’s
secure against strong adversaries, and showing that servers. AnonPoP uses two types of servers: Post-Office
it is practical even for mobile clients. We show that (PO) servers and timed mixes (see Figure 1). The PO
AnonPoPensuresbetteranonymitypropertiesthanev-
TwoCentsforStrongAnonymity:TheAnonymousPost-officeProtocol 3
ThePOmaintainsanonymousmailboxescontaining
envelopes sent to different clients. Envelopes received
by the PO are still encrypted; hence, a corrupt, eaves-
dropping PO cannot identify the recipients, senders
or contents, provided that the mixes are honest, and
users are always connected. (AnonPoP has defenses for
Fig.1.SystemarchitectureofAnonPoP(AnonymousPost-office
anonymity when users may disconnect, as we describe
Protocol).ThePost-Office(PO)maintainsanonymousmailboxes;
in next section.)
clientspushandpullenvelopesto/fromthemailboxanonymously
viamix-cascades.Allcommunicationchannels(representedby AnonPoP mailboxes are used only for a limited pe-
arrows)usefixedrates. riod,calledanepoch.Attheendofeveryepoch,senders
and recipients switch to a new (pseudo)random mail-
box, further limiting the potential for a corrupt PO to
and mix servers are expected to operate continuously;
correlate users of the same mailbox.
clients may disconnect from time to time.
AnonPoP supports multiple Post-Office (PO) AnonPoP has several additional defenses against
servers,whereeachclientselectsarbitrarilyaPOserver corrupt, eavesdropping PO. Such defenses are only
needed when clients may disconnect, or mixes may ac-
foritsuse.Aswelaterdescribe,AnonPoPallowsdetec-
tively collude with the PO (e.g., in ‘tagging’ attacks):
tion of tagging attacks by corrupt PO, and we expect
clients to move, in this case, to a different PO; however Request-Pool: a set of pre-made requests, allowing
preservation of anonymity even when a client dis-
wedonotdiscusstheprocessofmigratingtoanewPO,
connects. This is especially appropriate for pull-
and, for simplicity, our discussion and figures are for a
requests, allowing the pattern of collecting en-
single PO. Similarly, AnonPoP supports an arbitrary
velopes from a mailbox to be independent of pos-
number of mix servers, among which the client selects
sible disconnections of the destination.
mix-cascades; AnonPoP detects tagging attacks by cor-
ruptmixservers,andclientsavoidsuspectserverswhen Tag-Prevention: mechanisms such as de-duplication
and fixed forwarding times of requests and re-
selecting the mix-cascade, as discussed toward the end
sponses, which prevent active tagging attacks,
of this section.
where some of the mixes collude with the PO to
Envelopes are onion-encrypted as they are for-
identify sender or recipient. However, these mecha-
warded andmixedbythe mixes.Envelopescan contain
nismsdonotpreventalltheactiveattackswhenthe
either a push request, ‘pushing’ an envelope to a partic-
attacker controls both the first mix and the PO.
ular mailbox in the PO, or a pull request, ‘pulling’ an
envelope from a particular mailbox. Bad-Server Isolation: this mechanism detects a cor-
rupt (mix or PO) server, or a pair of two ‘consec-
More specifically, mixes operate in synchronized
utive’ servers s.t. (at least) on of the pair is ma-
slots of τ seconds. Each mix collects all envelopes re-
licious (and deviates from the protocol). In such
ceived in a slot, mixes their order, decrypts requests
cases, clients avoid the corrupt mix or the use of
and encrypts responses, and forwards them so they are
the suspect pair of mixes (i.e., the ‘suspect edge’).
all received in the following slot. Clients send envelopes
Thebad-serverisolationmechanismensuresastrict,
with push and pull requests every round of λ slots. If a
low limit on the amount of de-anonymizing queries
clientdoesnothavearealmessagetopush,shesendsa
availabletotheadversary,inspiteofitscontrolover
dummy[43]envelope,whichisrecognizedanddiscarded
by the PO. However, the PO responds to dummy re- a significant number f of corrupt (mix and/or PO)
servers.
quests as it does for real requests. This ensures unob-
servability against eavesdroppers and even mixes, i.e,
AnonPoP has a modular two-layer design. In this
an attacker controlling mixes and eavesdropping on the
communication,butnotcontrollingthePO,cannoteven work we mostly focus on the lower, Anonymous-
distinguish between the case that no messages are sent communication (Anon-Comm) layer, which ensures a
and the case that many messages are sent between dif- strongly-anonymous communication channel between
ferent users. Such attacker also cannot identify source clients and the PO. The upper Anonymous Post-Office
or destination, or even link between incoming and for- Box (Anon-POB) layer of AnonPoP handles mailboxes
for recipients. In this paper, we present only the simple
warded envelopes.
per-epoch mailbox design. We believe that further im-
provements in security, anonymity and efficiency, may
TwoCentsforStrongAnonymity:TheAnonymousPost-officeProtocol 4
be possible, by more elaborate Anon-POB layer mech- assuming probabilistic polynomial time attackers, e.g.,
anisms, which are beyond the scope of this paper. encryption schemes [6].
Mix selection.Forsimplicity,inthispaper,weas- AnonPoP design assumes that the attacker has
sume that AnonPoP clients and servers use a trusted, global eavesdropping abilities, i.e., can (instantly) ob-
reliable server directory service for path selection; this serveallcommunicationsentbetweenanyoftheparties
ismerelyasimplification,asitisstraightforwardtoim- in the system. We also consider additional attacker ca-
plement such a directory service in a distributed man- pabilities,mainly,controlofthePOand/orsomeofthe
ner (avoiding a single point of failure). The directory mixes,allowingcomplex,powerfulattacks.Althoughwe
maintainslistofallAnonPoPmixandPOservers,with allowanattackertocontrolsseveralcolludingserverssi-
their public keys and addresses. Furthermore, the di- multaneously, we make the reasonable assumption that
rectory lists pairs of connected servers; a pair of servers the number adversarial servers is limited.
(x,y)isconnectedifthedirectorydidnotreceivereport We also consider the communication to be between
from x claiming misbehavior of y. These misbehavior trustingpeers(senderandrecipient).Infact,wealready
reports are facilitated AnonPoP’s bad server isolation work on an advanced POB layer for AnonPoP that will
mechanism. As long as clients choose paths uniformly defend against malicious peers, however, this is beyond
(among all valid paths), the probability of choosing a the scope of this paper.
path containing only bad mixes remains very small.
We assume a known upper bound f to the num-
3.2 Challenges of Defining Anonymity
berofmalicious(faulty)mixservers;oncethedirectory
contains more than f reports for a specific mix or PO
Intuitively, anonymous communication means the in-
server, this server must be indeed corrupt, and is dis-
ability of identifying specific (communicating) enti-
connected from all other servers. Clients pick a cascade
ties among the set of potentially-communicating enti-
mix uniformly among all paths consisting of pairs of
ties. Multiple variants were considered by researchers
connected mixes, ending in the desired PO.
and practitioners, e.g., unobservability and sender
Mailbox setup. AnonPoP automatically assigns
(and/or recipient) anonymity. One widely-used inter-
clientstorandommailboxesandgeneratesproperkeys.
pretation[42]isthatsender(recipient)anonymityrefers
Inthispaper,weassumethatclientshaveasecurecom-
totheinabilityofanattackertoidentifythesender(re-
municationchanneltoperformtheinitialkeyexchange.
cipient) of a message among a set of potential senders
Anonymous key-exchange, e.g. in [25], is a further chal-
(recipients),andunobservabilityreferstoinabilityofan
lenge, which is beyond the scope of this paper.
attackertoknowwhethertherewasanycommunication
atall.Theseareuseful,intuitivenotions;however,they
3 Anonymity Properties are not sufficiently formal to allow rigorous proofs of
security.
This section presents the anonymity properties en- Transforming such informal, intuitive notions into
suredbyAnonPoP.Section3.1introducestheadversary precise, well-defined, formal definitions, is a non-trivial
model. Section 3.2 discusses the challenge of defining challenge.Therehavebeenmultipleattemptstopresent
anonymity properties, arguing that the existing rigor- appropriate formal definitions, including [2, 9, 26, 27,
ous, formal definitions are too simplified to cover the 30, 32–34, 41, 45, 47]. These definitions differ in multi-
goals of AnonPoP; in this paper we focus on presenting ple aspects, and in particular, in the capabilities of the
the AnonPoP design, therefore, extending the formal adversary, and in what constitutes a successful attack.
definitionsisleftforfuturework.Instead,inSection3.3 Unfortunately, when trying to apply these defini-
wepresent‘informalnotions’,whichweuseinthiswork. tions to analyze AnonPoP, we realized that each of
Section3.4describestheanonymitypropertiesachieved them, fail to satisfy all of the following three important
by AnonPoP, using the (informal) notions. aspects of AnonPoP’s design and goals:
1. AnonPoP’sgoalistoensurestronganonymityprop-
3.1 Adversary Model erties - against active, adaptive adversaries, who
eavesdrop the entire network and control a major-
As in previous works, we focus on probabilistic polyno- ity of AnonPoP’s servers. Existing definitions are
mial time attackers; this is essential, since our design for passive, static adversaries.
uses cryptographic mechanisms, which are only secure
TwoCentsforStrongAnonymity:TheAnonymousPost-officeProtocol 5
Attack:Defense(claim)
Honestserver Anonymityproperty
Withoutdisconnections Withdisconnections
Onlyfirst Passive:Prevent(2)
pushmix Sender Active:Prevent(3) Heuristicdefense,see
Onlynon-first anonymity Passive:Prevent(2) Section6.2andAppendixA
pushmix Active:Detect(4)
Onlyfirst Passive:Prevent(2)
pullmix Recipient Active:Prevent(3) Passive:Prevent(5)
Onlynon-first anonymity Passive:Prevent(2) Active:Detect(6)
pullmix Active:Detect(4)
OnlyPO Unobservability PassiveandActive:Prevent(1)
Table1.AnonymitypropertiesachievedbyAnonPoPagainstaglobally-eavesdroppingattacker,whocontrolsallserversalongthe
path,exceptasindicatedinthe‘honestserver’column.Inparentheses:numberofrelevantclaim.
2. AnonPoPsupports(limited-duration)clientdiscon- To present the (slightly weaker) notions of sender and
nections,anaspectwhichisnotaddressedbyexist- recipient anonymity, we first present sender/recipient
ing definitions, yet is crucial for a practical system, permuted pairs.Considertwoscenariosσ ,σ ,whereall
0 1
supporting mobile devices. the recipients receive the same messages in σ and in
0
3. AnonPoP is provides different levels of anonymity σ , but the senders in σ are a constant permutation
1 0
against attackers with different capabilities; this is (chosen by the attacker) of the senders in σ . Namely,
1
not compatible with current formal definitions. In given a permutation π chosen by the attacker, when a
particular, against some (strong) attack models, honestclientineedstosendamessagetorecipientr in
AnonPoP can ‘only’ ensure that attackers become σ , the honest client π(i) needs to do the same in σ .
0 1
increasingly isolated, hence deterring such attacks We say that σ and σ are sender permuted pair.
1 0
and reducing likelihood of successful attack; this is Similarly,thetermrecipient permuted pairrefersto
not captured by any of the existing formal defini- two scenarios where the recipients in one scenario are
tions. a permutation of the recipients in the second scenario,
and the senders are identical.
Since our focus in this work is on system design, we de-
cidedtoonlyfollow‘thespirit’oftheexistingdefinitions
Notion 2. (Anonymity)Aprotocolachievessender(re-
of anonymity, and use intuitive notions of anonymity
cipient) anonymity against a globally eavesdropping at-
(as we present in subsection 3.3) instead of formal def-
tackerthatcontrolsasetS ofAnonPoP’sservers,ifthe
initions; future work should extend existing definitions
adversary cannot (with significant advantage and in ef-
to provide a well-defined notion of practical anonymity.
ficient time) distinguish between any sender (recipient)
permuted pair of scenarios.
3.3 Informal Anonymity Notions
These notions pose great challenges because they also
Our notions follow [27], which addressed the challenge
consider extreme scenarios that might not occur in re-
of defining anonymity properties in the presence of ac-
ality. For example, for unobservability, the adversary
tive,adaptiveadversarieswhomightcontrolsomeofthe
must not be able to distinguish between any two sce-
protocolparticipants.Webelievethatthemodelof[27],
narios, even a scenario where all parties send messages
which extends [33], may be a good basis for a complete
vs. a scenario where nobody sends any message. These
formalmodelandanalysisofAnonPoP-infutureworks.
arestronganonymityrequirements.Inparticular,surely
We begin by presenting the notion of unobservabil- they do not hold for any low-latency solution such as
ity. Tor, since adversary can easily distinguish between the
scenarios. Furthermore, we allow also corruption of dif-
Notion 1. (Unobservability)Aprotocolachievesunob-
ferent subsets including most of the servers, as follows.
servabilityagainstagloballyeavesdroppingattackerthat
Detection/Isolation. Existing formal definitions
controls a set S of the servers, if the adversary cannot
of anonymity, e.g., in [27, 33], require complete pre-
(withsignificantadvantageandinefficienttime)distin-
vention of attacks. However, sometimes prevention is
guish between any pair of scenarios.
infeasible or hard/expensive, and a detection/isolation
TwoCentsforStrongAnonymity:TheAnonymousPost-officeProtocol 6
approach is sufficient to deter attackers and hence to pletelypreventsevenactiveattacksonsender(resp.,re-
ensureanonymity.Inparticular,inAnonPoP-andpos- cipient)anonymity.However,ifthefirstmixismalicious
sibly in other efficient strong-anonymity solutions - the then AnonPoP can only detect active attacks on sender
PO may ‘signal’ the use of a particular mailbox, by in- (resp., recipient) anonymity, and only when some other
tentionally dropping responses (or, equivalently, ignor- (non-first)push(pull)mixishonest.AnonPoPcansim-
ingrequests);such‘signal’seemsalmostunavoidablefor ilarly only detect, not prevent, sender anonymity, even
the model where the PO keeps mailboxes, yet, we show when the first mix is honest, if disconnections are pos-
that every such abuse is detected and isolated to a spe- sible; recipient-anonymity is fully protected (thanks to
cific rogue entity (e.g., the PO). the request-pool mechanism).
Intuitively, our goal is to ensure that every ‘bit’ of However, AnonPoP detection are very effective; in
informationcollectedbytheadversaryhasa‘highprice’. each detection, the client detects that the first mix is
We present an intuitive notion, which is somewhat tai- malicious, and/or at least one edge connecting a mali-
lored to the AnonPoP model. cious server and another (malicious or honest) server is
removedfromthegraphofAnonPoPserversmaintained
Notion 3. Let X(f),Y(f) be two functions (in the bythedirectory.Hencetheamountof‘deanonymization
number of corrupt servers f), and let xc be the num- queries’ is very limited (specifically, O(f2)).
ber of bits that the adversary can learn on (honest) user
c (communicating only with honest peers), and y =
c
max{0,x −X(f)}.Aprotocolachieves(X,Y)-attacker- 4 AnonPoP Basic Defenses
c
isolation if, with high probability, P y ≤Y(f).
c c AnonPoP uses onion encryption [14, 29], for both push
and pull channels, as illustrated in Figure 2. Namely,
Intuitively, the attacker can learn up to X(f) bits ‘per
requests are onion-encrypted, i.e., encrypted using the
client’, plus up to Y(f) bits additional (for all clients);
public key of the PO, and then, consecutively, by the
in AnonPoP, X(f) = f and Y(f) = f(f +1), as we
public keys of the mixes. Onion-routing trivially pro-
show below.
tectstheconfidentialityofrequests,sincerequestsmust
be decrypted by all mixes, and finally by the PO.
3.4 AnonPoP’s Anonymity Properties
Tofurtherpreventlinkagebetweenarequestenter-
ing a mix, and the corresponding (decrypted) request
We first consider the anonymity properties of Anon-
output by the mix, each mix buffers all messages re-
PoP, as a function of the malicious servers along the
ceivedduringaslot,randomlypermutesthemandsends
paths between the senders and recipients, as summa-
them in the following slot.
rizedinTable1.Asindicatedinthebottomrow,itsuf-
To similarly prevent linkage between incoming and
ficesforonlythePOtobehonestforAnonPoPtoensure
outgoing responses, each mix encrypts the responses.
complete unobservability. Similarly, it requires only one
Weuseauthenticated-encryption[5],allowingtheclient
mix in the push (pull) channel, to provide protection
to also validate that the response was sent by the PO,
for sender (resp., recipient) anonymity, if clients never
over the specified sequence of mixes; the PO sent the
disconnect.Recipientanonymityisprotectedevenwhen
responseuponreceivingthecorrespondingrequestfrom
clientsmaydisconnect(forreasonably-longperiods),by
the client. To facilitate the authenticated-encryption of
usingtherequest-poolmechanismofSection6.1.Inpar-
responses, clients include the authenticated-encryption
ticular,AnonPoPresistsintersectionandcorrelationat-
key to be applied to the response in each onion-
tacks [7, 8, 37, 52] between senders and recipients.
encryption layer (denoted key ,key ,key in Figure 2).
When clients may disconnect, AnonPoP cannot 1 2 3
AnonPoP uses two additional layers of encryption,
fully ensure sender anonymity, as an eavesdropping PO
on top of the onion encryption. First, messages pushed
canlaunchesintersectionandcorrelationattackstocor-
toamailbox,areencryptedforthedestination;namely,
relate between senders and mailboxes. Instead, Anon-
whenthePOdecryptsthefinalonionlayer,itfindsonly
PoP includes a heuristic-mitigation mechanism, per-
a mailbox identifier and an encrypted message. Second,
epoch mailboxes (PEM), to improve sender anonymity.
all the communication between every pair of adjacent
For discussion of the protection provided by PEM, see
entities(adjacentmixes,lastmixandPO,orclientand
Section6.2andexperimentalevaluationinAppendixA.
first mix) is authenticated and encrypted.
Asshowninthetable,whenthefirstpush(pull)mix
is honest, and without disconnections, AnonPoP com-
TwoCentsforStrongAnonymity:TheAnonymousPost-officeProtocol 7
Claim 1. AnonPoP ensures unobservability against a
global-eavesdropping adversary which further controls
any subset of mixes and users, and has the ability to
disconnect users, as long as the PO is not corrupted.
Argument: This follows by reduction to the indistin-
guishability property of (1) the public key encryption
scheme E , used to encrypt requests to the PO, and
PK
of (2) the shared-key encryption scheme E , used by
SK
thePOtoencryptresponses.Namely,assumesome(ef-
ficient)adversaryAisabletodistinguishbetweensome
two scenarios of message sending S ,S . We first check
0 1
if A also distinguishes between scenarios S0,S0, which
0 1
arethesameasthecorrespondingS ,S exceptthatre-
0 1
Fig.2.Onion-encryptionwithcascadesofmixes,asusedbyboth
sponsesfromthePOareall(encryptionsof)somefixed
pushandpullchannels.Thecirclesabovethestraightlinesmark
message m. If A succeeds, we use it as oracle to distin-
therouteoftherequestfromtheclienttothePO.Theresponse
routeisillustratedbysquaresbelowdashedcurves.Thesenders guishEPK;otherwise,weuseAtocreateoracletodistin-
encodesineachonionlayerakey(keyi)whichMixi usestoau- guish ESK (utilizing the fact that A fails to distinguish
thenticateandencrypttheresponse,andtimestampsTireq,Tires betweenS00 andS10,yetsucceedstodistinguishbetween
specifyingwhentherequestandtheresponseareexpectedtoar- S and S ). Notice that the reduction works since the
0 1
rive(seeSection5).Thesenderandmixesselecteacharandom
patternoftransmissionsisfixed,independentlyofinput
identifierID (forsender)orIDi (forith mix),andstorerelevant
messages.
parameters(keyi,Tires andreceivedID)intableMapindexed
bychosenID. Thepaddingandonion-encryptionmechanismsalsosuf-
fice to ensure sender and recipient anonymity, against
a passive (‘honest-but-curious’) attacker, as long as at
To prevent traffic analysis attacks, AnonPoP uses
least one of the mixes in the corresponding channel is
padding. First, all requests and responses use fixed-
notcorrupted.However,thisholdsonlywhenclientsare
sized envelopes (padding and fragmenting as needed).
always connected, since a (passive) corrupted PO may
Furthermore, AnonPoP maintains fixed rate of trans-
be able to identify a mailbox used by a client which is
mission of envelopes, independent of the pattern of re-
disconnected (e.g., using intersection attacks). We later
quests from the users. Namely, AnonPoP clients queue
present additional mechanisms of AnonPoP that pro-
outgoing messages if their rate exceed the fixed rate,
vide anonymity also when clients may disconnect.
and pushes dummy (empty) envelopes, if no outgoing
messagesarequeued.Dummyenvelopesaretreatedex- Claim 2. When clients are always connected and some
actly like ‘real’ messages; even mixes forwarding onion- push (pull) mix is non-corrupted, AnonPoP ensures
encryptedmessagescannotdistinguishbetweenrealand sender (recipient) anonymity against passive attackers.
dummy envelopes. Dummy envelopes are sent to a re-
Argument: We present the argument only for sender
servedmailboxidentifier,allowingthePOtodropsthem
anonymity; the argument for recipient anonymity fol-
(afterdecryptingthelastonionlayer);thePOresponds
lows similarly. The argument is by reduction to the in-
withadummyresponse,whichisindistinguishablefrom
distinguishability of the public key encryption scheme
a ‘real’ response, until decrypted and discarded by the
E , used to encrypt requests to the mixes, and in par-
client. PK
ticular, to the non-corrupt mix. Namely, assume some
As a result of these padding mechanisms, Anon-
(efficient) adversary A is able to distinguish between
PoP’s traffic is fixed, independently of the actual pat-
some two scenarios of message sending S ,S , where
tern of messages sent by clients. Together with the 0 1
the number and length of messages sent to each mail-
onion-encryption, this ensures unobservability as long
box(recipient)areidentical(senderanonymity).Dueto
as the PO is not corrupted, i.e., against a globally-
AnonPoP’s padding mechanisms, the pattern of trans-
eavesdroppingattacker,whichcontrolsmixesandusers.
missions is fixed, independently of input messages; and
This is simply because only the clients and the PO can
due to the operation of the (non-corrupt) mix, the or-
distinguish between dummy and real messages.
der of requests arriving at the PO is random. Hence, A
TwoCentsforStrongAnonymity:TheAnonymousPost-officeProtocol 8
provides an oracle allowing (efficient) distinguisher for 5.1 Timestamps and Anti-Duplication
E .
PK
It may seem, at first sight, that the padding and onion- The basic anti-tagging mechanism in AnonPoP, is to
routing mechanisms also suffice to ensure anonymity include timestamps in every layer of the onion; the re-
againstactiveattacks,ifthefirstmixinthecorrespond- quest(respectively,response)timestampfortheith mix
ingchannelisnon-corrupt,sinceanon-corruptfirstmix is denoted Treq (Tres).
i i
suffices to randomize the order of requests (responses) Non-corrupt mixes always return an encrypted re-
reaching the other mixes and the PO. However, this re- sponse exactly on the time specified in the timestamp
lying would be vulnerable to PO tagging attacks, where field; if the expected response is not received on time,
the number or timing of responses are tampered to al- then the mix returns an appropriate error report. A re-
low deanonymization. In the following section, we dis- sponse received too late (or too early) is dropped. Note
cuss tagging attacks and the defenses against them in that error reports sent when a response is not received
AnonPoP. on time, are indistinguishable compared to the ‘real’
Forward and proactive security. Finally, we note responses. The adversary cannot learn whether an en-
that it is quite simple for AnonPoP to also ensure for- crypted response hides either ‘real’ response or ‘error
ward secrecy and proactive security. Forward secrecy report’.
refers to protecting past communication from future Figure3(a)depictsataggingattackbydelayingthe
server compromise, and have been discussed in circuit response; in this attack, the PO delays the response for
related system such Tor [39]. To ensure forward se- a single request and can detect which client gets her
crecy, AnonPoP simply uses forward-secure encryption response one slot later. Figure 3(b) depicts the effect
scheme,e.g.,[12].Proactivesecurityreferstorecovering of fixed response time; honest mixes return response in
security (and secrecy) following a temporary compro- timeanddiscardlateresponses,hencetheattackersees
mise of a server; to ensure this, use the method of [11] noanomalyinthecommunicationpatternoftheclient.
to recover security for the keys used by each server. To further detect duplicate requests and responses,
received at the same (correct) time slot, each AnonPoP
mix uses the key it receives key , as a unique identifier.
i
5 Anti-Tagging Defenses
If a mix receives multiple requests with the same key
(at the same slot), then it discards all but one of them,
The onion-encryption and padding mechanisms de- sending back an error-report containing the plaintext
scribed in Section 4, cannot fully protect anonymity and randomness, allowing previous mix to validate the
againstaroguePO.Therearefewwaysinwhicharogue collision of keys. Similarly, a mix discards all but one
PO, possibly colluding with some mixes, can ‘tag’ a re- responseforeachforwardedrequest.(Randomcollisions
quest and/or the corresponding response, allowing it to occur with negligible probability.)
link between the client sending the request (and receiv- Figures3(c,d)depictduplicate-requestattack,when
ing the response) and the mailbox to which the request only a single (non-first) mix is honest, and the effect of
wassent.Inthissection,wepresentAnonPoP’sdefenses the anti-duplication mechanism. Figure 3(e,f) depicts
against such tagging attacks. similar duplicate-response attack and its prevention;
Inthefirstsubsection,wepresentAnonPoP’stimes- thisattack(anddefense)alsoappliesforthecasewhere
tamping and anti-duplication mechanisms, which pre- (only) the first mix is honest.
vent tagging attacks when the first-mix is honest, and
Claim 3. AnonPoP ensures sender (recipient)
always detecttaggingattacks.Inthesecondsubsection,
anonymity against active attackers, provided that the
wepresentthebadserverisolationmechanism,ensuring
firstpush(pull)mixishonestandthatclientsarealways
that whenever a tagging attack occurs at a particular
connected.
round, not only is it detected, but at least one edge
connected to a malicious server is removed from Anon- Argument: Due to the padding mechanism, requests
PoP’sgraphofavailablelinks.Thenextsectionextends aresentexactlyoncearound,withfixedsize.The(hon-
the mechanisms presented here, to also handle discon- est)firstmixshufflestheserequests,hence,thefollowing
nections of clients. mixes, and the PO, cannot link between the client and
a specific request from the first mix. The traffic from
the first mix back to the client is also fixed, since the
mix returns response exactly on the time specified in
TwoCentsforStrongAnonymity:TheAnonymousPost-officeProtocol 9
5.2 Bad Server Isolation
AnattackerwhocontrolsboththefirstmixandthePO
candrop,delayorcorruptrequestsand/orresponsesto
correlate between clients and mailboxes. The first push
(pull)mixknowstheoriginatorsofeverypush(pull)re-
quest,andthePOknowshowmanymessagesreacheach
mailbox. Even when clients do not disconnect, the PO
(a) Delayingtheresponse (b) Defensebyreturningan
arrival.Onlythefirstpull errorreportindistinguishable andthefirstmixmaytrytomatchclientstomailboxes,
mixishonest. fromarealresponseonthe bydroppingordelayingrequestsand/orresponses;this
expectedresponsetime. may allow an intersection attack; see Appendix A.1.
The bad-server isolation mechanism, allows Anon-
PoP to efficiently deter active attacks involving a rogue
firstmixandthePO.Previousworks,e.g.[24]discussed
the complexity of achieving such goal. The mechanism
extends the fixed-response time mechanism. Suppose
mix M detects that it did not receive the expected re-
sponse in its specified time from the ‘next server’ (mix
(c) Sendingaduplicatedre- (d) Defensebydroppingthe
questinafollowingslot.Onlyduplicatedrequestthatar- or PO), say denoted X. Then M encrypts and sends
onenon-firstpullmixishon- rivedonwrongslot. back a signed and time-stamped problem report, stat-
est. ingtherelevantidentities(M,X);the(signed)problem
report is also deposited at the AnonPoP directory.
As a result, all clients and servers, quickly learn to
avoidusingthepair(M,X)aspartofAnonPoProutes.
Namely, a rogue, active server, ‘loses’ one of its edges
to other servers, per each slot in which it uses such ‘ag-
gressive, detectable’ tagging attack.
As the path is chosen uniformly among all the re-
(e) Sendingaduplicatedre- (f) Defensebydroppingthe
liable paths, dropping connections with up to f honest
sponseinthesameslot.Only secondresponsereceived.
mixes prevents the choice of many paths where at least
onenon-firstpullmixishon-
est. onemixishonest,andbythat,increasestheprobability
of choosing a path where all the mixes are malicious.
Fig.3.Attackstocorrelaterecipientandhermailbox(ontheleft
Yet, while the fraction of malicious mixes is low, the
side)andtheirdefenses(ontheright).
advantage gained by the attacker is not significant; see
Appendix B.
the time-stamp field; due to the anti-duplication mech-
Claim 4. When clients are always connected, Anon-
anisms, only a single such response is sent (and only on
PoP achieves ((f,f ·(f +1))-attacker isolation.
that slot).
The encryption applied to messages ensures that eaves- Argument: A server reported by f +1 servers, where
droppers and other mixes cannot link between the f is bound on number of malicious servers, is definitely
senderandthe(encrypted)requests.Additionally,inev- malicious and not used in any channel. Note that the
ery two scenarios that are different only in the senders attacker cannot frame an honest server. Note also, that
(recipients), the same number of messages is pushed since we assume that at least one mix along the path is
(pulled) to (from) mailboxes that differ only by their honest,itfollowsthatthePOandfirstmixcanonlysig-
pseudonym, so the PO cannot distinguish between the naltoeachotherviatheabsenceofarequest/response,
two scenarios. Notice, that in this case, delaying or i.e., one bit per round; they cannot, for example, use
blockingofanencryptedmessagecanbedoneonlywhen content-based signaling. For each such learned bit, a
all the messages are already shuffled by the honest first disconnectionoccursbetweenonemaliciousmixandan-
mix, and hence, such active attacks are not helpful and other mix, either due to false report by the attacker or
Notion 2 holds. due to a real report by the honest mix. Beyond that,
each of the mixes can operate as a first mix for each
TwoCentsforStrongAnonymity:TheAnonymousPost-officeProtocol 10
of the clients and to drop the message to tag the user When a client is connected, the first pull-mix has
without blaming the next mix. In such case, the first this ‘pool’ containing µ pull requests, prepared in ad-
mixwillnotbedisconnectedfromanothermix,butthe vance, for the µ next rounds. As long as the client re-
client knows for sure that the first mix is malicious and mainsconnected,ineveryround,onepullrequestisused
hencedisconnectsfromit.Theoretically,thisallowseach toretrieveamessage,andtheclientprovidesanewpull
of the f mixes to tag each of the users once. The num- request, maintaining µ requests in the ‘pool’.
berofbitscanbelearnedaccordingtoeachofthecases This ‘pool’ allows the first pull-mix to send a pull
satisfies Notion 3. requestfortheclient,eveninroundsinwhichtheclient
is disconnected (up to µ consecutive rounds). The mix
alsoholdsalltheencryptedresponsesreceivedfromthe
6 Handling Disconnections
PO; the mix does not know whether the responses are
real or dummy.
Clients using mobile devices may often disconnect from When a client reconnects after being disconnected
the network. Such disconnections may be observable - for x ≤ µ rounds, it contacts the first pull-mix to re-
sometimes even controlled - by the attacker, allowing trieve messages kept by the mix from the previous x
an attacking PO to correlate between clients and the rounds. The client also sends to the mix x+1 new pull
mailboxes they pull from, using intersection and corre- requests, to be used in future rounds, replenishing the
lationattacks[7,8,37,52].Inparticular,ifapullrequest ‘pool’ of µ requests. In every other round, the client
reaches some mailbox, an eavesdropping PO can learn sends the pull request that will be used µ rounds after
that all the clients who were offline when the request the current round.
arrived are not the owner of the mailbox. By repeating
Claim 5. AnonPoP ensures recipient anonymity
thisprocedureovertime,theadversarymaycorrelatea
against passive attackers when some pull mix is honest,
single recipient with the mailbox.
even when clients may disconnect, if clients do not go
Section 6.1 describes the request-pool mechanism
offline for more than µ consecutive rounds.
that ensures recipient anonymity, provided that clients
do not disconnect for excessive time periods. In Sec- Argument: Since the adversary is passive, the traffic
tion 6.2 we discuss the challenge of ensuring sender from/to the first pull mix to/from the PO is fixed (as
anonymity when client might disconnect, explaining though there were no disconnections). There might be
why using request-pool also for push requests may a peak in the traffic between the first pull mix and the
be problematic. We then introduce a simple mecha- client immediately after the client reconnects, i.e., the
nism, per-epoch mailboxes (PEM), which heuristically rateoftrafficbetweentheclientandfirstmixisnotcom-
improves the sender anonymity, although not satisfying pletely fixed. However, the traffic is still independent of
ournotionforsenderanonymity(Notion2).Webelieve the actual number of messages sent and received, and
that further research on mailbox mechanisms may fur- depends only on the connectivity of the clients. Since
ther improve AnonPoP’s anonymity defenses. theconnectivityisknowntotheeavesdroppingattacker,
thenthismechanismexposesnoadditionalinformation.
Hence, there is no information leakage.
6.1 Request-Pool
Sinceclientsnotofflineformorethanµrounds,recipient
anonymityis achieved againstpassiveattackersaccord-
We now explain request-pool, a simple yet effective
ing to Notion 2, provided that (at least) one pull mix
technique allowing AnonPoP to extend its recipient-
is honest. This is because all the pull requests and the
anonymity defenses to the case of (reasonably-limited)
responses for the requests arrive to a honest mix that
client disconnections, and in particular, to foil intersec-
forwards them shuffled, and the adversary cannot cor-
tion and correlation attacks. We focus on pull-requests,
relate between incoming messages and outgoing mixed
where the defense works better, utilizing the fact that
messages.
pull requests do not contain content that depends on
themailboxstatus.Specifically,eachclientpreparesand Claim 6. AnonPoP achieves ((f,f ·(f +1))-attacker
sendstothefirstpull-mixa‘pool’ofpullrequeststobe isolation, even when clients may disconnect, provided
used in future rounds, even in rounds where the client f << n and clients do not go offline for more than µ
is disconnected. consecutive rounds.