DP5: A Private Presence Service

Transcription

1 DP5: A Prvate Presence Servce Nkta Borsov Unversty of Illnos at Urbana-Champagn, Unted States nkta@llnos.edu George Danezs Unversty College London, Unted Kngdom g.danezs@ucl.ac.uk Ian Goldberg Unversty of Waterloo, Canada ang@cs.uwaterloo.ca ABSTRACT The recent NSA revelatons have shown that address book and buddy lst nformaton are routnely targeted for mass ntercepton. As a response to ths threat, we present DP5, a cryptographc servce that provdes prvacy-frendly ndcaton of presence to support real-tme communcatons. DP5 allows clents to regster and query the onlne presence of ther lst of frends whle keepng ths lst secret. Besdes presence, hgh-ntegrty status updates are supported, to facltate key update and rendezvous protocols. Whle nfrastructure servces are requred for DP5 to operate, they are desgned to not requre any long-term secrets and provde perfect forward secrecy n case of compromse. We provde securty arguments for the ndstngushablty propertes of the protocol, as well as an evaluaton of ts performance. 1. INTRODUCTION We kll people based on metadata. General Mchael Hayden [11] Many organzatons, from hobbyst clubs to actvst groups to socal meda gants, provde a mechansm for ther members to engage n real-tme onlne communcaton wth ther frends. Ths s nowadays predomnantly done usng the federated XMPP [26] protocol wth ether web-based or standalone clents to access servces. A crucal part of a messagng servce s to provde ndcators of presence: when a person connects to the network, she would lke to be nformed of whch of her frends are currently onlne. Dependng on the exact detals of the communcaton servce, she may also wsh to be nformed of some extra data assocated wth each of her onlne frends, such as the frend s current IP address, preferred devce, encrypton publc key, or other metadata useful for establshng communcaton. Note that the communcaton tself may then occur n a drect peer-to-peer manner, outsde the scope or vew of the organzaton provdng presence servce. A typcal presence mechansm works by havng each user nform the server of who her frends are. Then, whenever those frends log n, they are nformed of the user s state (offlne or onlne), and f onlne, the assocated data. Note that the frend relaton s not necessarly symmetrc: f Alce lsts Bob as a frend, then Bob wll see Alce s presence nformaton, but not necessarly vce versa. Ths ubqutous and straghtforward presence mechansm, however, has a sgnfcant prvacy problem: the server learns the complete lst of who s frends wth whom, and when each user s onlne. However, we have recently observed that governments use legal compulson on servce provders to dsclose ther prvate data, as was the case for the Lavabt servce [25]. On January 2014 the New York Tmes also revealed documents, leaked by Edward Snowden, demonstratng that onlne address books and buddy lsts are prme targets for extra-legal survellance by the Unted States and Unted Kngdom s sgnal ntellgence agences [19]. As a result, organzatons provdng presence servce may be reluctant to even hold ths prvacy-senstve metadata. In ths work, we present DP5 the Dagstuhl Prvacy Preservng Presence Protocol P. 1 DP5 allows organzatons to provde a servce offerng presence nformaton (and assocated data) to ther users, whle usng strong cryptographc means to prevent the organzaton tself from learnng prvate nformaton about ts users, such as ther lsts of frends. The key contrbutons of ths paper relate to the desgn and analyss of DP5, a prvate presence system. More specfcally, we: Present a set of securty propertes, functonal requrements, and a desrable threat model for prvate presence. ( 3) Descrbe a desgn, DP5, that fulflls the securty requrements, based on prvate nformaton retreval and unlnkable pseudonyms n consecutve epochs. ( 4) Show that the DP5 securty mechansm provdes unlnkablty, and argue that t also provdes forward secrecy even when all nfrastructure components are compromsed. ( 5) Evaluate the system performance of all DP5 sub-protocols. ( 6) Dscuss desgn and mplementaton optons, to strengthen the securty of DP5 notably aganst clent compromse. ( 7) 2. RELATED WORK Presence s a fundamental component of a number of real-tme communcaton systems ncludng Voce over IP and chat protocols, such as IRC, XMPP, and MSN. One obvous desgn choce to acheve prvate presence conssts of smply runnng a conventonal presence system, or even a full chat server, behnd a mechansm provdng clent and server anonymty, such as a Tor hdden servce [16]. Whle ths mechansm may hde the denttes of users behnd pseudonyms, t does not hde the relatonshps among ther pseudonyms, and so can lead to re-dentfcaton nonetheless [24]. Laure s Apres [22] was the frst to suggest a prvacy-frendly protocol to acheve presence. Apres ntroduces the noton of epochs (and calls them ID du jour) and the basc scheme by whch presence nformaton s unlnkable between epochs (through hashng) to prevent traffc analyss. Apres also consders how presence s an essental mechansm to enable further effcent communcaton, a feature that DP5 ams to preserve. A specfc system makng use of an Apres-lke presence mechansm to facltate real-tme communcaton s Drac [13], whch proposes a smplfed presence mech- 1 The extra P s for extra prvacy. 1

2 ansm based on hashng. DP5 provdes an mportant addtonal securty property compared wth Apres (and Drac that bulds on t): t hdes the topology of the frend graph wthn each epoch. Snce Apres was proposed, a body of work has demonstrated that merely provdng unlkablty of dentfers between epochs does not prevent deanonymzaton of socal network graphs f ther topology remans the same [24]. Ths s true even f graphs between epochs are not completely somorphc due to mssng edges or vertces. The DP5 protocol elmnates ths de-anonymzaton possblty by splttng presence nto regstraton and lookups whereas Apres was confoundng the two and ensurng no topology nformaton leaks. The Tor Project s n the process of redesgnng the Hdden Servces mechansm [16], whch ncludes a few mechansms related to the goals of DP5. Current thnkng around hdden servces allows for servces wth secret addresses. To preserve ths secrecy, queres for the hdden servce to hdden drectory servces are obscured through blndng ther secret publc key wth a key derved from tself and an epoch. The core of ths rendezvous mechansm s smlar to the goals of the DP5 protocol, and has nfluenced our deas around forward secrecy. Presence s related to namng securty. DNSSec [1] and DNS- Curve [3] provde relable mappng between names and low-level Internet protocol addresses. DNSSec has been engneered to facltate offlne sgnatures, and s therefore not approprate to translate names to very dynamc nformaton lke presence and status. On the other had DNSCurve does support dynamc bndng of names to addresses, through stronger channel securty. Whle ths provdes prvacy aganst network adversares, and lmted traffc analyss protecton due to potental local cachng, t does not provde the strong forms of traffc analyss protecton DP5 was desgned for. The GNU Name System [28] and a recent proposal by Tan & Sherr [27] use a Dstrbuted Hash Table that all users mantan to mrror all peer s name records to rendezvous. As wth DNSSec, ths mechansm s ll-suted to dynamc nformaton due to the slow rate of DHT updates, and does not provde clear prvacy guarantees. 3. DESIGN AND SECURITY GOALS The DP5 servce ams to provde a prvate alternatve to presence systems that support real-tme communcatons such as nstant messagng or Voce over IP (VoIP). In a nutshell, users are able to regster and revoke frends, and query the servce to retreve the onlne status of those that lsted them as frends, as well as receve a small amount of extra nformaton useful for bootstrappng other securty protocols. From a securty perspectve, subject to some typcal cryptographc assumptons, the servce does not learn who s frends wth whom, the topology of the socal network remans secret, and no one s n a poston to fake the status of any honest user. Ths secton provdes detals about the propertes and threat model of the DP5 desgn. 3.1 Presence features DP5 acts as a presence mechansm, but s also enrched wth features that allow t to compose well wth, and provde a sold foundaton for, other secure protocols. It s assumed that through an out-of-band prvate channel users have acqured a publc key correspondng to each of ther frends. Ths can be done n practce through downloadng all publc keys, usng a physcal anonymous mechansm for transferrng the key (such as a USB drve or smart-phone), or usng a prvacy-frendly record retreval mechansm, such as prvate nformaton retreval (PIR). Once users have the lst of publc keys of ther frends they can use DP5 to perform a number of operatons: Frend Regstraton. A user Alce s able to use the publc key of a user Bob to regster Bob as her frend. As a result Bob s authorzed to receve Alce s onlne status and other assocated data. Presence Regstraton. Alce can regster her onlne status at a partcular tme perod (epoch), along wth a small amount of assocated data for that tme perod. The system should eventually detect Alce gong offlne at a later perod and change her status automatcally. Presence Status Query. A user Bob should be able to query the system and retreve the onlne status of those users that have regstered hm as a frend at a partcular tme perod (epoch). In partcular we note that both Alce must have regstered Bob as a frend, and Bob must ssue a query for Alce s status, n order for Alce s status to be provded to Bob. As part of the response to the query, the presence-assocated data of Alce s provded to Bob f she s onlne. Frend Suspenson or Revocaton. Fnally, Alce or Bob may decde that they wsh to not be frends any more. Alce can thus chose to remove Bob from her frends and not advertse to hm her presence, and Bob may chose to not query for Alce s presence or assocated data. If they only do ths temporarly we call the acton a presence suspenson, and n the long term call ths a presence revocaton. 3.2 Threat model and securty assumptons The DP5 desgn ensures some securty propertes for presence subject to some system and cryptographc securty assumptons, as well as some lmtatons on the partes an adversary can control or corrupt. However, the DP5 protocol s extremely robust aganst passve or actve network adversares. More precsely the securty of DP5 rests on the followng threat model: Secure end-user hosts. Throughout ths work t s assumed that honest users end systems are secure. In partcular DP5 makes use of publc-key encrypton, for whch the long-term prvate keys must reman confdental. Furthermore, the long-term publc keys of a user s frends dentfy the socal network that DP5 ams to protect, and thus, must be stored securely on a user devce. The securty of end hosts s an orthogonal problem to the one DP5 ams to solve. However, we dscuss n Secton 7.3 how to best partton an mplementaton of the DP5 protocol to store any long term keys nto secure hardware to protect aganst some software attacks. Smlarly t s assumed that honest servces run on secure end systems that can mantan secrecy and ntegrty as necessary. Servers are engneered to not requre long-term secrets, and provde forward secrecy, to mtgate any compromses. Computatonal cryptography assumptons. DP5 makes use of a number of cryptographc technques, and thus assumes that the adversary has not made cryptographc breakthroughs allowng hm to bypass them. In partcular we assume that the secure channels between honest users and honest nfrastructure servces provde the necessary authentcty, ntegrty and confdentalty. We also assume an adversary s not able to volate the propertes of a secure pseudo-random functon (PRF-IND), secure encrypton (IND- CPA) or volate the Decsonal Dffe-Hellman (DDH) assumptons or the co-dhp assumpton for blnear groups. (We elaborate on a varant that does not rely on parng-frendly ellptc curves n Appendx A, at the cost of some extra server-sde computaton and storage.) Ubqutous passve network observer and dshonest users. We assume an adversary can observe all the nformaton that s n tran- 2

3 st between all honest and dshonest partcpants n the protocols. All securty propertes should hold even for an adversary wth a full record of all network communcatons between all partes. An adversary can also make use of the presence system both by regsterng the presence of malcous users, as well as by queryng t n any manner. Threshold of honest nfrastructure servers. The DP5 protocol uses a coalton of nfrastructure servers to acheve ts goals. It s assumed that at least one of those servers does not collude wth the others to volate any securty propertes and executes the protocol correctly. Other servers may be passvely dshonest: n such a case they follow the protocol, but share ther nternal state and secrets wth the adversary. The DP5 protocol s desgned to mantan all ts securty propertes aganst such adversares. It may be the case that some other servers are actvely malcous, and do not follow the DP5 protocol. In such a case the DP5 protocol mantans ts confdentalty and ntegrty propertes, but may not provde some of ts functonalty namely, t may suffer from denal of servce. We dscuss how to amelorate ths ssue n Secton 7.4. Securty n the covert model. Fnally, some avalablty aspects of the protocol rely on the covert securty model, namely that adversares follow the protocol f devatons would be detected wth some non-neglgble probablty. Specfcally, we rely on ths model to argue that regstraton servers would not remove presence entres wthout due authorty. 3.3 Securty goals In ths secton we present the securty goals of the DP5 servce. It s worth notng that the securty propertes descrbed are n relaton to the addtonal nformaton that could be leaked by the presence protocol and not the communcaton channels used. Prvacy of presence. Only frends of Alce are able to detect whether Alce s or s not onlne. More formally, an adversary wth a transcrpt of the contents of DP5 protocol nteractons cannot dstngush whether Alce was one of the honest partcpants or not. Integrty of presence. Only Alce can convnce one of her frends that she s onlne. More formally, f an honest frend of Alce becomes convnced that Alce s onlne at a partcular epoch, t must be the case that Alce has performed the presence regstraton protocol for that epoch. Prvacy for socal network. Ether Alce regsterng frends or her presence, or Bob queryng for the presence of hs frends, should reveal no nformaton about who ther frends are. Gven any two lsts of frends (up to a publc maxmum length) for any honest partcpant n the DP5 protocol, t s ndstngushable to the adversary whch of the two lsts was used. Ths holds for all parts of the protocol, ncludng frend regstraton, presence regstraton, presence queryng, the storage or retreval of assocated data. Unlnkablty between epochs. User actons are not lnkable across epochs to an adversary that s not ther frend. Specfcally, gven a transcrpt of the DP5 protocol for a specfc user at an epoch, and a transcrpt at a subsequent epoch, an adversary cannot dstngush f the transcrpts orgnated from the same user or dfferent users. Prvacy of assocated data. Only frends can recover the plantext of a user s assocated presence data. If the adversary submts to the user two canddate plantexts, and the user chooses one as ther assocated data for a specfc epoch, the adversary cannot effcently dstngush whch of the two was chosen. Integrty of assocated data. If an honest frend of Alce recovers a plantext of assocated data t must be the case that Alce ran the assocated data regstraton protocol at that epoch, wth that plantext as nput. Indstngushably of offlne status, suspenson and revocaton. A user Bob even f Alce had regstered hm as a frend n the past cannot dstngush whether Alce s offlne, has suspended hm, or has revoked hm as a frend. Audtablty of nfrastructure. All actons that the centralzed regstraton servces perform should be publcally verfable. In partcular a publc append-only log of all actons of regstraton servers should not volate any securty propertes. Forward and backward secrecy of nfrastructure. An adversary wth the power to extract cryptographc keys from nfrastructure servers at some pont n tme, cannot compromse the securty of any past epochs. Once fresh authentcaton keys are generated future uses of DP5 are also safe. Optonal support for anonymous channels. The DP5 protocol does not leak any addtonal nformaton about the dentty of clents than do the underlyng communcatons channels. In partcular, f the communcaton channels leak no dentty, nether does DP5. We note that the ntegrty of presence property s enforced by an audtng mechansm, and that the ntegrty of assocated data requres ether the mechansm descrbed n Sect. A or the use of dgtal sgnatures. 4. THE DP5 PRESENCE PROTOCOL 4.1 Protocol descrpton The objectve of the DP5 protocol s, broadly, for users to advertse ther presence status to ther frends only, wthout revealng ther socal network to any sngle thrd party. The protocol assumes a number of partcpants collaborate to acheve ths: users, one of whch we call by conventon Alce, regster ther presence n the system to a regstraton servce; users, such as one called Bob, can then query the servce to retreve the status of users for whom they are frends. The servce s composed of a regstraton server, handlng the user regstraton sde of the protocol, and a number of prvate nformaton retreval (PIR) authortes handlng the query sde of the protocol. For clarty of presentaton we wll pn Alce s role as wshng to advertse her presence to her frend Bob, whle Bob only queres the system for Alce s presence. Of course, n practce, all partes partake n both the regstraton and query protocols, and have multple frends. 4.2 DP5 setup The DP5 protocol assumes that Alce and Bob share a cryptographcally strong symmetrc secret keys K ab (we note that these keys have a drecton, thus the key K ba s also shared but dfferent from K ab ). Ths key can be computed through Alce and Bob generatng a publc-prvate key par usng a group G, generated by element g, n whch the Decsonal Dffe-Hellman problem s beleved to be hard (such as the Ellptc curve group of Curve25519 [2]), and securely exchangng the correspondng publc keys. An approprate key dervaton functon can be used to extract K ab and a dfferent K ba. The DP5 protocol does not requre ths shared key to be stable n the long term; thus, t s also possble for Alce and Bob to use a mechansm offerng perfect forward secrecy to derve the shared key perodcally. The DP5 protocol dvdes tme nto short-term epochs, meant to last on the order of a few mnutes, and long-term epochs, on 3

4 the order of a day. Clents and nfrastructure are assumed to have loosely synchronzed clocks. All partes to the DP5 protocol share a common set of cryptographc prmtve: three famles of keyed pseudo-random functons (PRF l K(m), l {1, 2, 3}, mplemented usng SHA-256 [17]); an authentcated encrypton prmtve (AEAD IV K (h; m)) 2 (such as AES [12] n GCM mode [23]); and access to secure channels between clents and nfrastructure (usng TLS [15]). Furthermore, DP5 makes use of three generators g 1, g 2 and g T of groups G 1, G 2 and G T respectvely for whch an effcently computable asymmetrc parng functon e(g 1, G 2) G T s known, such that e(g1 a, g2) b = gt a b. The Decsonal Dffe-Hellman problem s assumed to be hard n each of these groups (so that a type 3 parng [18], wthout an effcently computable somorphsm from G 2 to G 1 or the reverse, s n use), as well as the Co-DHP (aka Co-CDH) [5] problem for G 1 and G 2. An effcently computable hash functon H 0 : G T {0, 1} η from elements of G T to η-bt strngs s known by all (η s the length of an dentfer). Everyone also knows two effcently computable hash functons H 1 : T G 2 (where T s the set of vald epoch tmestamps) and H 3 : G 1 {0, 1} ν (where ν s the key sze of the PRF 3 functon). Fnally, all users share some global parameters, such as a maxmum number of frends N fmax, the number N prmax of PIR servers and ther IP addresses, the sequence number and duraton of shortterm (t ) and long-term (T j) epochs, and the byte sze of all nputs and outputs of the cryptographc prmtves. 4.3 PIR sub-protocol DP5 uses prvate nformaton retreval (PIR) n order to allow clents to retreve presence nformaton from DP5 servers wthout revealng to the servers what nformaton s beng requested. A basc PIR prmtve s to consder a database of r blocks, each b bts n sze, where the clent knows the exact ndex of the block she wshes to retreve. In DP5, we use nformaton-theoretc PIR, n whch multple (non-colludng) PIR servers are employed. The clent nformaton-theoretcally splts her query across the set of N prmax servers, and combnes ther responses n order to reconstruct the data n queston. A non-trvalty requrement s that the amount of data transferred n the protocol s sublnear n the total sze of the database (rb bts). Probably the smplest such scheme s due to Chor et al. []. Ths smple scheme sends r bts to, and receves b bts from, each server, for a total communcaton cost of N prmax (r + b) bts. However, ths scheme s not robust: f one of the servers fals to respond, or responds ncorrectly, the clent wll fal to reconstruct her data, and ndeed wll be unable to dentfy the server(s) that responded ncorrectly. Goldberg [20] demonstrated a PIR protocol wth only margnally larger communcaton costs: N prmax (rw + b) bts, where w s the btlength of the underlyng fnte feld (typcally w = 8). Ths protocol, however, s able to handle offlne and malcous servers. Devet et al. [14] recently further extended the robustness of ths protocol, enablng reconstructon of the requested data, and dentfcaton of the msbehavng servers, when only t + 2 servers are behavng honestly. Here, t s the prvacy level: any colluson of up to t servers learns no nformaton about the query. Ths protocol s mplemented n the open-source Percy++ lbrary [21], whch we use n our mplementaton of DP5. Our stuaton s not qute as smple as the above protocols pro- 2 We omt h when the AEAD mode s not used to provde ntegrty over any cleartext data (what the AEAD calls assocated data not to be confused wth the DP5 assocated data). vde for, however. Our databases consst of a collecton of (key,value) pars, and our goal s to retreve the value correspondng to a gven database key, rather than a partcular block ndex. To do ths, we buld upon the block-retreval PIR prmtve above, usng an extenson to Chor et al. s hash-based PERKY protocol [9, 5.3]. Ths extenson works as follows: Let s be the (fxed) sze (n bytes, as we use w = 8) of the (key,value) par, and let there be n such pars ready to be nserted nto a database at the start of a shortterm or long-term epoch. The hgh-level dea s that we wll create r = ns buckets, and use a hash functon on the keys to hash the (key,value) pars nto the buckets. The expected sze of each bucket s then n data tems, or n s bytes, and usng Chernoff bounds, t s r r easy to see that the probablty of one bucket contanng more than n + n data tems s neglgble. In practce, we select the hash r r functon by pckng ten random PRF keys for a PRF wth codoman {1,..., r}, usng each to hash all n keys n the database, and fnd the largest number of records hashed nto any one bucket. We then keep the PRF key that yelded the smallest such largest bucket. That PRF key s made avalable to DP5 clents when they contact the PIR database servers. Ths hash varant s more sutable for our purposes than the perfect hash n PERKY, as our (key,value) records are small n comparson to the number of such records, so we want to have many records n a sngle PIR database block n order to balance the sendng and recevng communcaton cost. PERKY, on the other hand, uses perfect hashng to put zero or one keys (they do not consder assocated values, but ths s a trval extenson) nto each PIR block, and uses n 2 blocks of sze s bytes to accomplsh ths, whle we use r ns blocks of sze about ( n + ) n r r s 4 ns + ns 3 bytes. As the underlyng PIR protocol we use transmts a number of bytes equal to the number of records plus the sze of each record, and the computaton cost s proportonal to the number of records tmes the sze of each record, our hash-based protocol s preferable to that of PERKY n our envronment. 4.4 DP5 regstraton Alce regsters her presence and assocated data for each epoch, by updatng a number of databases at epoch t 1 and T j 1, that are made avalable for all to query at epoch t and T j. Long-term epoch frendshp database. Once per long-term epoch T j 1, Alce updates the long-term epoch frendshp database for the next long-term epoch T j wth a record for each of the frends she wshes to advertse her presence. The database s an oblvous repostory of records for each drected frend lnk n the system; however, note carefully that ths database does not leak nformaton about the actual frendshps to those wthout the approprate secret keys. To perform ths update, Alce pcks a random prvate key x R G 1, and derves a fresh publc key Pa j = g1 x. Then for each of her frends she derves the shared key for the long-term epoch, and encodes a database entry comprsng an dentfer, and a cphertext of her fresh publc key. For nstance, Alce encodes an entry for Bob usng ther shared key K ab for long-term epoch T j as follows. She frst derves an epoch key usng a pseudo-random functon and the dentfer for the long-term epoch: K j ab = PRF1 K ab (T j). She then creates a publc dentfer for the key as ID j ab = PRF2 K ab (T j), and encrypts her publc key as C j ab = AEAD0 K ab(id j j ab ; P a j ). The resultng entry s (ID j ab, Cj ab ). Alce encodes an entry for each of her frends, and then pads the lst of entres wth random entres up to a maxmum number of frends N fmax. Those random entres are generated by Alce performng the encodng process above usng a randomly chosen fresh 4

5 shared key. She then sends the fxed-sze lst of entres to the regstraton server, whch stores t. Alce stores the fresh prvate-publc key par (x, P j a ) untl a new one s generated. We call the publc component P j a the ephemeral epoch key of Alce. Short-term epoch user and sgnature database. Once per shortterm epoch t 1, Alce updates the short-term epoch user database for epoch t wth a sngle entry, denotng she s onlne, and some assocated data m a. Alce frst derves s a = H 1(t ) x, whch represents an unforgeable sgnature that Alce s onlne. Furthermore, Alce encrypts her assocated data as c a = AEAD K (ma). where a Ka = PRF 3 (t). She then sends the record H 3 (Pa j ) (s a, c a) to the regstraton server. The regstraton server, upon recevng an entry (s a, c a) from Alce, frst derves an dentfer ID a = H 0(e(g 1, s a)). Then the server updates two parallel databases: the entry (ID a, c a) s added to the short-term epoch user database for t, and the entry (ID a, s a) s added to the short-term epoch sgnature database. 4.5 DP5 query At the begnnng of epoch T j the regstraton servce makes publc the full long-term epoch frendshp database wth all entres receved durng epoch T j 1. Smlarly, at the begnnng of each short-term epoch t, the regstraton server makes avalable the separate short term user and sgnature databases wth collected durng epoch t 1. All PIR servers download all databases as soon as they become avalable. Furthermore, each PIR server audts at the start of t the user database usng the entres n the sgnature database: each entry (ID a, c a) n the user database corresponds to an entry (ID a, s a) n the sgnature database, such that ID a = H 0(e(g 1, s a)). If the audt succeeds the PIR server proceeds to answer requests for entres n the databases. Once per long-term epoch T j Bob queres the long-term frendshp database for entres correspondng to each of hs frends. Frst, he reconstructs for all hs frends a shared dentfer; e.g., for Alce he computes the dentfer ID j ab = PRF2 K ab (T j). He then pads ths lst of frend dentfers wth a number of random dentfers, up to a maxmum number of frends N fmax. Fnally, usng a PIR protocol, he queres the long-term frendshp database for the fxed-length lst of dentfers. As a result, he receves a lst of dentfer and cphertext entres (ID j fb, Cj fb ), one for each of hs frends f who regstered n epoch T j 1. For each of those entres, for example Alce s, he decrypts cphertext C j ab usng key Kj ab = PRF1 K ab (T j) to yeld plantext Pa j. Upon vald decrypton he updates hs knowledge of the publc key of Alce wth the ephemeral epoch key decrypted, namely Pa j. Up to once per short-term epoch t, Bob may wsh to refresh the status nformaton of hs frends ncludng Alce. As a frst step, Bob reconstructs the dentfer of Alce usng the latest publc key Pa j avalable for her. To ths end he computes ID a = H 0(e(Pa j, H 1(t ))) for Alce, and smlarly an ID for each of hs other frends. He then prvately queres the PIR servers for a lst of those dentfers, padded wth random strng to a maxmal length of N fmax. Upon completon of the retreval protocol, Bob decrypts each returned cphertext entry wth a symmetrc key derved as Ka = PRF 3 (t). If the decrypton succeeds the status of H 3 (Pa j ) the frend s set as onlne, and the assocated data m a s returned. Otherwse the frend s status s set as offlne, and no assocated data s returned. 4.6 Usage notes Epoch lengths. The presence mechansm s dvded nto long-term epochs and short-term epochss, wth dfferent performance characterstcs. In the long-term epoch the regstraton phase has a space complexty of O(fmax), where fmax s the maxmal number of frends. However, n the short-term epoch the regstraton space complexty s merely O(1), makng short-term updates extremely effcent. Both mechansms requre O(fmax) queres to the database, through the PIR mechansm. However, the sze of the database s dfferent n each case: the long term database s larger and contans O(N fmax) entres, where N s the number of dstnct regstered clents, whereas the short-term database only contans O(N) entres makng queres cheaper. Skppng short-term epochs. A deployment can leverage ths asymmetry to provde extremely tmely updates. The long-term epoch can be set at the granularty of a day, whle the short-term epoch can n the order of magntude of mnutes. Clents regster ther presence n the long-term epoch, and also at regular ntervals n the short-term database. To detect presence t s mperatve that all clents have an up-to-date vew of ther frends entres from the long-term database, snce ths enables them to use the shortterm update mechansm. Ths s relatvely nfrequent, and therefore cheap n terms of processng and bandwdth costs. Clents can choose, accordng to avalable resources, how often they wsh to query the short-term database. Short-term queres can be scheduled ether for each short-term epoch, perodcally but less frequently than the short-term epoch nterval, or on-demand when a hgh-level (observable) acton that requres presence nformaton s undertaken. The frequency of updates may depend on load, network avalablty, or any other non-senstve nformaton but must not be dependent or adapt to the actual presence nformaton retreved n prevous epochs. Such adaptve strateges create a tmng sde-channel that the adversary could use to nfer the frends of a clent whch s exactly what DP5 attempts to obscure. Suspendng presence and revocaton. The cost of longer longterm epoch s n terms of nflexblty of suspenson or revocaton of presence. In order for Alce to selectvely revoke a frend Bob, she must not use hs Dffe-Hellman publc-key when she regsters wth the long-term frendshp database, and also change her shortterm publc key. Any updates to the long-term frendshp database can only take place once the long-term epoch changes, and thus the mmedacy of revocaton depends on ths perod beng short. Smlarly, addng a new frend only fully takes place at the next long-term epoch. However, addng someone can be very fast when an out-of-band channel s avalable: Alce can exchange wth them not only her Dffe-Hellman key but also her publc key P j a for the current long-term epoch, so they can mmedately start queryng the short-term user database. Mssng the long-term epoch update. Whle long-term epochs should be long enough to provde a good wndow of opportunty for Alce to regster, she mght occasonally not be able to. In those cases, by conventon, her frend may stll seek her presence n the short-term database by usng her last known ephemeral epoch key. Alce, aware that she mssed a long-term update, may reuse her prevous fresh publc key for one or more addtonal long-term epochs untl she s able to regster agan n the long-term frendshp database. Note that both Alce and her frends can determne whch was the last regstered publc key, through queryng past epochs of the frendshp database. Users of the system may be tempted to skp lookng up past longterm updates for specfc frends, and use the above mechansm as long as there s no change n Alce s lst of frends. Whle ths does not lead to any mmedate securty breach, t s dscouraged. Fllng n long-term updates. Alce s frends may also be offlne 5

6 long enough to mss a partcular long-term epoch update. The DP5 protocol assumes that all clents check for ther frends presence each long-term epoch. Therefore t s necessary to request, usng the full PIR mechansm, all epochs that have been mssed sequentally. Clents may be tempted to only query a subset of recent epochs, untl they have dentfed the latest long-term update for all ther frends. Whle ths may be cheaper than requestng all updates, the stoppng rule depends on the secret lst of frends of a clent, resultng n an observer recevng nformaton about the lst of frends by observng the number of requests. Consequently we requre all clents to sequentally query all long-term epochs, even though ths may leak to the adversary how long they have been offlne. Self-checkng our own entres. A partal audtng mechansm s ncluded n DP5 through PIR servers checkng sgnatures on the database of entres. However, ths only guarantees that malcous msleadng entres are not ncluded n the databases, but not that the regstraton server does not drop vald entres. Each clent can perform some lmted checks to reduce the lkelhood of a malcous regstraton server not servng the full database. A clent can query the database for keys that t regstered correspondng to some of ts frends, to check they are ncluded and served correctly. The DP5 protocol may be extended wth the regstraton servers provdng a sgned recept upon each regstraton, to allow non-ncluson of records to be verfed by thrd partes. Ths audtng mechansm s qute robust: once the databases are provded to the lookup servers selectve denal of servce by the regstraton server s no longer possble. Furthermore, the prvacy propertes of PIR ensure that the queres to the known entres are perfectly prvate and do not leak any nformaton about the dentty or any other secret of the clent. Snce DP5 requres clents to query a maxmum number of entres ths audt process can consume unused slots and does not add any extra cost, as long as the clents have fewer frends than the maxmum allowed. 5. SECURITY ARGUMENT We present an analyss of the securty propertes of DP5. Prvacy of presence. The long-term protocol uses shared keys that are derved va Dffe-Hellman key agreement; an adversary wthout access to the prvate keys cannot assocate the shared key wth a user. In the short-term protocol, Alce s so-called publc key, g x 1, s revealed only to her frends (va the long-term protocol), and thus a regstraton usng the correspondng prvate key cannot be ted to Alce. Integrty of presence. In the long-term protocol, presence nformaton s authentcated usng AEAD wth a shared key. In the short-term protocol, a presence regstraton requres H(t j) x, whch s a BLS sgnature [6] on the epoch number t j. The securty of BLS for Type-3 curves was proven by Chatterjee et al. under an assumpton they call Co-DHP*, whch they show to be equvalent to Co-DHP [5] under a unform generator assumpton [8]. Because ths sgnature s not ncluded n the PIR database, a corrupt regstraton server collaboratng wth one of Alce s frends could convnce her other frends that she s onlne, but ths wll be caught by the PIR servers usng the partal audtng mechansm. Prvacy for socal network. Just as the long-term regstraton protocol does not reveal Alce s dentty, t lkewse hdes the denttes of her contacts. On the query sde, the prvacy of the socal network s preserved through the PIR subprotocol. Unlnkablty between epochs. The proof of ths property s gven n Appendx B. Prvacy and ntegrty of assocated data. Ths s ensured by the AEAD algorthm. Note that n the short-term protocol, the AEAD key s known to all of Alce s frends, and so one frend, collaboratng wth the regstraton server, could supply ncorrect assocated data for the regstraton. Unlke presence ntegrty, ths wll not be caught by the PIR servers audt. Ths could be remeded by generatng an addtonal sgnature on the assocated data, at the cost of sgnfcantly ncreasng the sze of the short-term database. Indstngushablty of offlne status, suspenson, and revocaton. To revoke or suspend Bob s access, Alce chooses a new publc key Pa j and does not share t to Bob. To mantan ndstngushablty, Alce may generate a separate key P ˆ a j and share t wth Bob through the long-term database. Alce can use Pa j n the short-term regstraton protocol, but from Bob s pont of vew, Alce wll always appear as offlne, as a consequence of the prvacy of presence property. Audtablty of nfrastructure. The above prvacy propertes do not rely on the regstraton server mantanng any secrets and so a publc audt log of regstraton messages wll not volate any securty propertes. Forward secrecy of nfrastructure. The long-term secrets of the PIR servers are used only for establshng TLS connectons. Assumng that TLS s used n forward-secure mode, ther compromse does not reveal any nformaton about past regstratons. (The servers should take care, however, not to store the plantext PIR requests or responses after ther use.) A compromse of the long-term secrets of the regstraton server can affect ntegrty only, and thus do not enable the compromse of past nformaton. Optonal support for anonymous channels. Alce s dentty s not revealed n the regstraton protocol, as guaranteed by the prvacy of presence and unlnkablty between epochs propertes. The use of PIR n the query protocol, n turn, fully hdes the dentty of the querer. 6. EVALUATION 6.1 Implementaton We mplemented the DP5 protocol as a set of lbrares, as well as clents and servers usng those lbrares. The cryptographc core reles on OpenSSL for AES and hash operatons, as well as the TLS channels between clents and servers (usng self-sgned certfcates). The AEAD functon s nstantated wth 128-bt AES n Galos Counter Mode (GCM) and an all-zero IV (snce all keys used are fresh). Parng-frendly curves are provded by the RELIC lbrary, and we use the Percy++ lbrary [21] for the robust PIR functons. The DP5 lbrary s mplemented n C++ (00 lnes of.h fles, and 4800 lnes of.cpp fles), and the network code n Python 2.7 (2700 lnes of.py fles). These nclude unt test code, functonal test code, ntegraton tests, and expermental setup code. All clent-server nteractons are encoded as web requests usng the lghtweght Cherrypy framework, and both clents and servers are buld around the Twsted non-blockng network lbrares. The core lbrary nterfaces wth the hgh-level network code usng both natve bndngs and the CFFI foregn call nterface for Python. We wll be releasng our code under an open-source lcense. 6.2 Performance To evaluate the performance of DP5, we ran 960 smultaneous clents accessng the DP5 nfrastructure. The clents were runnng on an 80-core Xeon 2.4 GHz server wth 1 TB of RAM. For 6

7 Latency (s) Latency (s) Latency (s) Latency (s) Tme (s) (a) Regstraton (long-term) Tme (s) (b) Lookup (long-term) Tme (s) (c) Regstraton (short-term) Tme (s) (d) Lookup (short-term) Fgure 1: An executon trace of 960 clents. Table 1: Data szes Long-term Short-term Req Resp Req Resp DB sze 12 MB 80 KB Regstraton B 5 B 164 B 5 B Lookup 300 KB 500 KB 5 B 80 KB 3 each of the short-term and long-term protocols, we used one server for regstraton and three servers supportng PIR (8 servers total). Each server was runnng on a 16-core Xeon 2.0 GHz machne wth 256 GB of RAM. The machnes were nterconnected usng 1 Gbps Ethernet. Fgure 1 shows the trace for 30 mnutes of executon. Each pont corresponds to a completed operaton, wth the x-coordnate representng the tme of completon and the y-coordnate the latency from the tme the operaton was started. To better understand the mpact of both short- and long-term epoch changes, we set ther length to be 1 and mnutes, respectvely. Clents are roughly synchronzed and begn regstraton and lookup requests at the begnnng of each epoch, whch results n a roughly lnear pattern of responses observed n the graph. The performance s somewhat worse n the frst epoch as new TLS connectons must be establshed to the servers; the connectons are reused for future queres. Note that when a long-term epoch changes, clents are unable to ssue meanngful PIR requests to the short-term database untl they have receved the (potentally) updated keys from the long-term database; ths can be seen n the smaller number of short-term lookup requests every mnutes (Fgure 1d). A more realstc value for the long-term epoch would be 24 hours, mnmzng the mpact of ths problem. Further, clents could optmstcally use prevous keys n lookups, falng only n cases of key change. Fgure 2 summarzes the user-facng latency of the operatons over a 5-hour executon. The box plot depcts the nterquartle range, wth a lne representng the medan, and the range of 99% of the ponts, wth outlers plotted as ndvdual ponts. We emphasze that these delays are a consequence of the synchronzed behavor of the clents. For the short-term epoch, we expect ths to represent real-world behavor, but for the long-term epoch, clents wll come onlne durng dfferent parts of an epoch and thus experence lower delays. Montorng the behavor of the servers, the PIR servers for the long-term database had hgh CPU utlzaton for the approxmately 90 seconds followng an epoch change; other servers were mnmally utlzed and thus appear to be able to support sgnfcantly larger numbers of clents. Table 1 lsts the szes of the requests and responses n our protocol, excludng the overhead from the HTTP and TLS protocols. 6.3 Scalng The bottleneck server-sde lookup operatons nvolved n DP5 are easly parallelzable and thus more resources can be deployed to support larger user populatons. As the number of users grows, the database sze wll grow lnearly wth the number of users. Our PIR mplementaton uses bandwdth that grows as Θ(n 1/2 ) wth respect to the sze of the database and thus remans practcal for sgnfcantly larger user populatons. The per-user server-sde computaton for PIR, however, s lnear n the database sze. The long-term PIR server s the most resource-ntensve compo- 3 Our mplementaton automatcally selected the trval PIR protocol (.e., downloaded the entre database) for the short-term protocol as ths was more bandwdth effcent than PIR for ths sze of database. 7

8 Latency (s) Regstraton (long-term) Lookup (long-term) Regstraton (short-term) Lookup (short-term) Fgure 2: Overall user-facng latency for the regstraton and lookup operatons Monthly per-user cost ($) Total Bandwdth CPU e+06 1e+07 Number of users Fgure 3: Per-user cost for the bandwdth and CPU assocated wth runnng a long-term PIR server wth a 24-hour epoch. nent of DP5. In our experments t used about 15 CPU-mnutes and 1 GB of bandwdth per epoch. Fgure 3 plots an estmate of the cost of runnng such a PIR server, usng $0. as the cost of one CPU-hour and 1 GB of data transfer 4, and a 24-hour epoch. A user populaton of can easly be supported even wth volunteer resources, whereas a subscrpton servce can support as many as mllon users at a per-user cost of less than $/month. 7. DISCUSSION 7.1 Channel anonymty The DP5 desgn allows clents to access presence servces through anonymous, pseudonymous or authentcated channels. The presence servce s guaranteed to preserve the propertes of the channel and leak no more nformaton about the dentty of the clents, and ther frends, than the channel already would allow an adversary to nfer. For clents that use DP5 over authentcated or pseudonymous channels, t provdes relatonshp anonymty only. An adversary does not learn the frends of any clents but can observe a spe- 4 Ths cost s arrved at by roundng up Amazon s EC2 prces ( We note that cloud-computng provders are not an deal ste for a PIR server, as the provder could not necessarly be trusted to reman honest and preserve users prvacy, but they do provde a useful baselne for estmatng the costs of computng resources. cfc clent or pseudonym beng onlne / offlne. Ths nformaton s leaked by the channel, not the presence servce. Usng the DP5 servces over an anonymous channel provdes both relatonshp anonymty, and unlnkablty across long-term and short-term epochs, vs-a-vs the presence servce. However, most deployed anonymty systems do not provde full unobservablty, and therefore do leak when a network end-pont s usng the anonymty network and when t s out of t. Therefore, despte an adversary observng the DP5 nfrastructure not beng able to nfer the onlne / offlne profle of a clent, t mght be able to do so f the clent s under drect observaton. Channels that offer unobservable access to anonymty networks may mtgate aganst ths attack. 7.2 Suspenson, revocaton, and pseudonyms We dvde tme nto short-term and long-term epochs n order to balance up-to-date presence wth tmely revocaton. For Alce to revoke Bob she removes hs publc key from the long-term update mechansm, and refreshes her short-term publc key. Ths results n Bob not beng able to retreve the next fresh short-term publc key for Alce, and so he cannot query her short-term presence or assocated data. Alce may selectvely allow Bob to query her presence n specfc epochs. However, once Bob has access to her key for a specfc long-term epochs, the presence mechansm s all-or-nothng: ether all frends, ncludng Bob, get updated or none does. To acheve fner temporal control over whch frends can or cannot see updates from Alce, she has to use multple pseudonyms. Ths can be acheved by dvdng her frends nto a mutually exclusve sets, and provdng each set wth a dfferent fresh short-term publc key. Durng any short-term epoch Alce can regster wth all, or any subset of the ephemeral publc keys to advertse her presence to dfferent sets of frends. However, regsterng multple pseudonyms durng a short-term update s susceptble to traffc analyss. An adversary can observe the number of short-term updates orgnatng from Alce to nfer the number of sets of frends she advertses to, whether she s not advertsng to some sets, and even to dentfy her between dfferent short-term or long-term epochs f the number of pseudonyms s atypcal. For ths reason advertsng multple pseudonyms s best done when usng anonymous channels, by repeatng the full short-term regstraton protocol once for each pseudonym. 7.3 Forward secrecy and hardware stores Varous parts of the DP5 protocol have been desgned, or can be easly altered, to provde stronger guarantees aganst end-pont compromse. Purely cryptographc mechansms can provde forms of forward secrecy, preventng retrospectve prvacy volatons n case keys are compromsed. Hardware modules wth a narrow nterface can be used to prevent long-term secrets beng extracted n case the software stack of clents s compromsed, as was the case n the recent Heartbleed attacks aganst OpenSSL. By desgn, long-term epoch regstraton reles on a derved key K ab that s the result of a Dffe-Hellman exchange. Once ths shared key between Alce and Bob s derved there s no need to store the publc or prvate keys that were used for the dervaton any more. Smply usng fresh key pars wth dfferent frends, and deletng them after the frst key dervaton has taken place, s good practce. In the DP5 desgn subsequent long-term epoch keys, K j ab, are derved usng the master shared key K ab and the epoch dentfer T j. Ths enables the storage of long term shared keys nto a hardware securty module that only exports epoch key K j ab. As a result, f a clent s compromsed, only the keys relatng to the current 8

9 long-term epoch are accessble. Once the ntruson has been detected, subsequent keys should stll be safe. It s mportant to note that even ths lmted compromse has profound consequences that are not lmted n tme: once an adversary has access to Alce s secrets for one epoch, they can determne who her frends are. Thus ths mechansm only protects future updates of Alce s frends lst. Another opton provdes some lmted form of forward secrecy: we can modfy the key dervaton for long-term epochs to be K j ab = PRF 1 K j 1 ab (T j). Snce the long-term epoch shared key now only depends on the prevous long-term epoch keys, prevous keys can be securely deleted. Ths means that past databases cannot be analyzed by an adversary who compromses the keys. Ths mechansm does not protect future updates once keys are compromsed. Importantly, despte hardware storage of keys or the alternate dervaton of keys, a compromse not only leaks the presence and status of Alce for some epochs but also of all of her frends who have authorzed her to read ther status. Ths, we beleve, s a fundamental lmtaton of any prvate presence protocol: n case a user s compromsed the presence of all nformaton they were authorzed to read, ncludng the presence and status of ther frends, s compromsed. Thus, presence prvacy seems nevtably more fragle than end-to-end encrypton for whch perfect forward secrecy can be acheved, but rather smlar to group prvate communcatons, or long-term nformatonal leakage on socal networks. 7.4 Protectng Avalablty Ensurng avalablty aganst malcous clents, servers and thrd partes s especally mportant for protocols supportng prvacy, as tradtonal approaches, such as loggng, blacklstng or audtng may not be applcable. The frst challenge s to ensure the presence database remans small, by preventng malcous clents from addng a large number of entres. If the channels are authentcated, only the confdentalty of who s frends wth whom s mantaned (but not the prvacy of when Alce s onlne). In that case, tradtonal authentcaton can be used to ensure Alce only updates once per long-term and short-term epoch. In case Alce uses an anonymous channel, requrng authentcaton would compromse anonymty. In ths case, an n-perodc anonymous tcketng scheme, such as the one proposed by Camensch et al. [7] may be used to anonymously lmt regstratons per user. A second challenge s to ensure that the regstraton servers do not drop entres. To ensure that Alce s entres have been added to an epoch Alce may add herself to her frend lst, and check that her record s correctly returned by the servers. We note that due to the cryptographc propertes of our scheme t s nfeasble for the regstraton servce or the lookup servces to selectvely drop entres for specfc frends of Alce s, snce they are ndstngushable. Ths mechansm may be turned nto a robust audtng framework by requestng sgned recepts from servers for regstraton and lookups snce the database s publc, ths allows any thrd party to verfy a clam that they dd not nclude or serve a specfc challenge record. Fnally, lookup servers may modfy the database to drop records. We use robust PIR [14] that ensures that a malcous server would be detected. Preventng DoS requres at least t + 2 honest servers, where t s the maxmum number of servers that the threat model allows to collude to determne the query. 7.5 Implementaton lessons Implementng and measurng the DP5 protocols provdes us wth some nsghts on how to mprove ths type of protocol n the future; we attempt to share these nsghts n ths secton. The DP5 desgn assumes that a dfferent ephemeral key s generated and communcated between frends at each long-term epoch. Whle ths provdes forward secrecy, s also creates a sequental dependency between the long-term protocols and the short-term protocols. As a result, all on-lne clents must successfully query the long-term frendshp database before even attemptng to query the frst epoch of short-term epoch database. Ths creates a sgnfcant amount of congeston and delay. It s preferable to only requre the long-term frendshp database to be updated when the frendshp graph changes, and provde a mechansm for clents to only retreve the dfferences, whch should be small (we call ths desgn a delta database, but do not explore t further n ths work). Congeston becomes a problem n protocols that requre each clent to query each of the epochs at least once, as the number of clents ncreases. The current desgn of DP5 s not responsve to such congeston, and clents wll keep retryng to query overloaded servers effectvely performng an unwttng Denal of Servce attack. It s clear that a control loop s necessary to regulate the length of an epoch, gven the degree of congeston experenced by the lookup servers the most loaded n the desgn. There s surprsngly lttle pror work on how to desgn secure control loops: If an adversary s able to modulate the load on the servers by performng multple queres, or smply lyng about ther load, a nave control loop would ncrease the epoch length and as a result degrade forward secrecy propertes or ncrease the latency of revocaton events. Thus secure load montorng would be needed to mplement secure control loops, whch s beyond the scope of DP5. 8. CONCLUSION We present DP5, the frst prvate presence mechansm to leak no nformaton about the topology of a contact lst network. We show that the servce can be realzed whle relyng only on ephemeral secrets on a set of dstrbuted nfrastructure servers. Thus, queryng the status of frends cannot be used n the future to trace them or de-anonymze the users. Furthermore, care has been taken to desgn a protocol that may be used when users are known to the nfrastructure, but also when users are anonymous wthout leakng any addtonal nformaton about ther dentty. Overall, the protocols are scalable to small deployments of a few thousands, to tens of thousands of concurrent clents, a sze sutable for small NGO or cooperatve ISP. The key scalablty bottle neck s the prvate nformaton retreval scheme, and any mprovement n PIR would drectly translate to an mprovement n the performance and scalablty of DP5. Fnally, DP5 supports real-tme presence, but ts latency s determned by the length of the short-term epochs. It s an open problem, and a challenge to the research communty, to devse protocols that could reduce ths latency radcally, whle requrng overall low bandwdth. Acknowledgments The authors would lke to thank Clauda Daz (KUL) and Roger Dngledne (Tor) for key dscussons relatng to the desgn of DP5, and Schloss Dagstuhl semnars for hostng those mportant desgn dscussons. We also thank Harry Halpn (W3C) and Eljah Sparrow (LEAP) for ther feedback on presence requrements, Mcrosoft Research Cambrdge for hostng two of the authors, and Danel J. Bernsten for suggestng that a parng-free varant of the protocol should be possble. Ths materal s based upon work supported by the Natonal Scence Foundaton under Grant No , and by NSERC, ORF, and The Tor Project. Ths work benefted from the use of the CrySP RIPPLE Faclty at the Unversty of Waterloo. 9

10 9. REFERENCES [1] Roy Arends, Rob Austen, Matt Larson, Dan Massey, and Scott Rose. DNS Securty Introducton and Requrements. RFC 4033, [2] Danel J. Bernsten. Curve25519: New dffe-hellman speed records. In Mot Yung, Yevgeny Dods, Aggelos Kayas, and Tal Malkn, edtors, Publc Key Cryptography, volume 3958 of Lecture Notes n Computer Scence, pages Sprnger, [3] Danel J. Bernsten. DNSCurve: Usable securty for DNS [4] Danel J. Bernsten, Nels Duf, Tanja Lange, Peter Schwabe, and Bo-Yn Yang. Hgh-speed hgh-securty sgnatures. Journal of Cryptographc Engneerng, 2(2):77 89, [5] Dan Boneh, Crag Gentry, Ben Lynn, and Hovav Shacham. Aggregate and verfably encrypted sgnatures from blnear maps. In El Bham, edtor, Advances n Cryptology EUROCRYPT 2003, number 2656 n Lecture Notes n Computer Scence, pages Sprnger Berln Hedelberg, January [6] Dan Boneh, Ben Lynn, and Hovav Shacham. Short sgnatures from the wel parng. In Coln Boyd, edtor, Advances n Cryptology ASIACRYPT 2001, number 2248 n Lecture Notes n Computer Scence, pages Sprnger Berln Hedelberg, January [7] Jan Camensch, Susan Hohenberger, Markulf Kohlwess, Anna Lysyanskaya, and Mra Meyerovch. How to wn the clonewars: effcent perodc n-tmes anonymous authentcaton. In Ar Juels, Rebecca N. Wrght, and Sabrna De Captan d Vmercat, edtors, ACM Conference on Computer and Communcatons Securty, pages ACM, [8] Sanjt Chatterjee, Darrel Hankerson, Edward Knapp, and Alfred Menezes. Comparng two parng-based aggregate sgnature schemes. Desgns, Codes and Cryptography, 55(2-3): , May 20. [9] Benny Chor, Nv Glboa, and Mon Naor. Prvate Informaton Retreval by Keywords. Techncal Report 1998/003, IACR, [] Benny Chor, Oded Goldrech, Eyal Kushlevtz, and Madhu Sudan. Prvate Informaton Retreval. In FOCS 95: Proceedngs of the 36th Annual Symposum on the Foundatons of Computer Scence, pages 41 50, Oct [11] Davd Cole. We Kll People Based on Metadata. New York Revew of Books, May [12] Joan Daemen and Vncent Rjmen. The desgn of Rjndael: AES-the advanced encrypton standard. Sprnger, [13] George Danezs, Clauda Daz, Carmela Troncoso, and Ben Laure. Drac: An Archtecture for Anonymous Low-Volume Communcatons. In Prvacy Enhancng Technologes, pages Sprnger, 20. [14] Caset Devet, Nada Hennger, and Ian Goldberg. Optmally Robust Prvate Informaton Retreval. In 21st USENIX Securty Symposum, Aug [15] T. Derks and E. Rescorla. The Transport Layer Securty (TLS) Protocol Verson 1.2. RFC 5246 (Proposed Standard), August [16] Roger Dngledne, Nck Mathewson, and Paul F. Syverson. Tor: The second-generaton onon router. In USENIX Securty Symposum, pages USENIX, [17] D. Eastlake and P. Jones. US Secure Hash Algorthm 1 (SHA1). RFC 3174, [18] Steven D. Galbrath, Kenneth G. Paterson, and Ngel P. Smart. Parngs for cryptographers. Dscrete Appled Mathematcs, 156(16): , September [19] James Glanz, Jeff Larson, and Andrew W. Lehren. Spy Agences Tap Data Streamng From Phone Apps, January [20] Ian Goldberg. Improvng the robustness of prvate nformaton retreval. In IEEE Symposum on Securty and Prvacy, pages IEEE Computer Socety, [21] Ian Goldberg, Casey Devet, Paul Hendry, and Ryan Henry. Percy++ project on SourceForge, June [22] Ben Laure. Apres a system for anonymous presence Techncal report. [23] Davd A McGrew and John Vega. The securty and performance of the galos/counter mode (gcm) of operaton. In Progress n Cryptology-INDOCRYPT 2004, pages Sprnger, [24] Arvnd Narayanan and Vtaly Shmatkov. De-anonymzng socal networks. In IEEE Symposum on Securty and Prvacy, pages IEEE Computer Socety, [25] Domnc Rushe. Lavabt founder refused FBI order to hand over emal encrypton keys. The Guardan, October [26] Peter Sant-Andre, Kevn Smth, and Remko TronCon. XMPP: The Defntve Gude: Buldng Real-Tme Applcatons wth Jabber Technologes. O Relly Meda, 1st edton, [27] Henry Tan and Mcah Sherr. Censorshp resstance as a sde-effect. In Securty Protocols Workshop, [28] Matthas Wachs, Martn Schanzenbach, and Chrstan Grothoff. On the feasblty of a censorshp resstant decentralzed name system. In 6th Internatonal Symposum on Foundatons & Practce of Securty (FPS 2013), APPENDIX A. DP5 WITHOUT PAIRINGS The short-term DP5 regstraton and update protocols make use of publc key prmtves over parng-frendly curves. Ths s necessary for Alce and Bob to compute a sgned short-term epoch dependent tag to detect Alce s presence and data. The sgnature prevents any thrd party, or even frend of Alce, from forgng her presence status. Danel J. Bernsten noted that these propertes can be acheved wthout the use of parng-frendly curves, but nstead conventonal ellptc curves that support secure dgtal sgnatures such as Ed25519 [4], as descrbed next. As part of the long-term regstraton, Alce stores n her status assocated data a publc key Pa j = g x that s a pont on an approprate ellptc curve. Durng short-term epoch each frend of Alce derves a varant of the publc key as Pa j = Pa j g H 4(Pa j ), where H 4 s a secure hash functon. Only Alce and frends of Alce can derve ths publc key snce t requres knowledge of the publc key Pa j ; furthermore, those publc keys are unlkable across short-term epochs. Furthermore, Alce can construct the prvate key correspondng to ths publc key whch s x = x + H 4(Pa j ). Both Alce and her frends can also derve a symmetrc key Ka = H 5(Pa j ) to protect the confdentalty of assocated data. To perform the short-term regstraton protocol, Alce stores n the database the tuple (Pa j, AEAD K (ma)). Furthermore, Alce a sends to the regstraton server a sgnature of the tuple under the

11 G 0 G 1 G 2 G 3 K acb c K j a cb c = pkskac b c = PRF 0 K acb c (T j) ID j a cb c = PRF 1 K acb c (T j) C j a cb c = AEAD 0 K j acb c (ID j a cb c ; d c ) z R g K j a cb c = PRF 0 g z (Tj) ID j a cb c = PRF 1 g (Tj) z C j a cb c = AEAD 0 K j acb c (ID j a cb c ; d c ) z R g R 1 R {0, 1} ν ID j a cb c = PRF 1 g z (Tj) C j a cb c = AEAD 0 (ID j a R cb c ; d c ) 1 R 1 R {0, 1} ν R 2 R {0, 1} η C j a cb c = AEAD 0 R 1 ( R 2 ; d c ) Fgure 4: Computng the challenge message for contact b c n successve games for the long-term protocol. η here s the length of the publc dentfer. key x. The regstraton server checks that the sgnature verfes under the verfcaton key ncluded as the frst element of the tuple, and then ncludes the tuple n the database. The full lst of tuples and sgnatures s made avalable to the lookup servers for audtng purposes. Fnally, Bob can use the short-term epoch publc keys of hs frends Pa j n the case of Alce to look up ther records n the database. The assocated data can be decrypted usng the symmetrc key Ka. Ths varant of the DP5 protocol has the advantage that s does not requre any parngs, and thus the clents requre fewer securty assumptons, and fewer dependences on cryptographc lbrares. It also allows for the assocated data to be sgned by Alce, and therefore t s unforgeable subject to the securty of the audtng mechansm. On the downsde, ths mechansm requres an addtonal sgnature on the data, whch n the orgnal DP5 s ntegrated wth the tag generaton. Ths overhead ncreases the sze of the short-term database, whch lnearly ncreases the cost of each PIR query over t. B. SECURITY PROOF OF UNLINKABILITY BETWEEN EPOCHS Regstraton Unlnkablty of the long-term protocol. We defne the followng game to represent regstraton unlnkablty: 1. The adversary supples the challenger wth: Two usernames, a 0 and a 1 A number of frends for the regstraton protocol, n Two sets of n frends, B 0 = {b 0 } n =1 and B 1 = {b 1 } n =1 Two sets of per-user data, D 0 = {d 0 } n =1 and D 1 = {d 1 } n =1 An epoch T j 2. The challenger generates a key for all users n U = {A 0, A 1} B 0 B 1 and sends the publc keys to the adversary. 3. The challenger flps a con to select a bt. 4. The challenger creates a regstraton message from user A c for epoch T j, wth contact set B c and per-user data set D c and sends t to the adversary. 5. The adversary may ask the challenger to generate keys for any other username u / U. The challenger returns a publc/secret key par to the adversary and keeps track of these new usernames by addng them to a set U. 6. The adversary may then query for regstraton messages generated by any user u U U n an arbtrary epoch, wth arbtrary lsts of contacts taken for U U and per-user data, wth the restrcton that users a 0 and a 1 cannot be asked to regster agan durng the epoch T j. 7. The adversary outputs ts guess for the bt c. We wll frst consder the case where n = 1;.e., the challenge regstraton ncludes a sngle contact. We defne the followng sequence of games, n whch the challenges changes the way that the challenge message s computed, as llustrated n Fgure 4. G 0 s the game where the challenger behaves correctly. In G 1, the challenger replaces the shared key K acb c wth 1 gz, for a unformly chosen z, nstead of the key computed by Dffe-Hellman. Note that any adversary A that can dstngush between G 0 and G 1 wth advantage ɛ can be turned nto an adversary A that solves the Decsonal Dffe-Hellman problem wth the same advantage: gven a DDH trple (g x, g y, g z ), A runs the challenger algorthm, usng g x as the publc key for a c, g y as the publc key for b c 1, and g z as ther shared key. (To compute the shared secret between a c or b c 1 and any other contact, the challenger can make use of that contact s secret key.) Observe that f z = xy, ths s equvalent to G 0 and f z s random, ths s equvalent to G 1. In G 2, the challenger proceeds as n G 1, but replaces K j a cb c 1 wth R 1 chosen unformly at random. Any adversary who can dstngush G 1 from G 2 wth advantage ɛ can be turned nto an adversary who dstngushes PRF 0 from random wth the same advantage, snce usng a random functon nstead of PRF 0 g z n G1 turns t nto G2. (Note that PRF0 gz s only ever evaluated n the computaton of the challenge message, except wth a neglgble probablty.) In G 3, we lkewse replace ID j a cb c wth R2 chosen unformly 1 at random. As before, an adversary who can dstngush between G 3 and G 2 can be transformed nto an adversary who can dstngush PRF 1 from random. In G 3, the regstraton message s (R 2, AEAD 0 R 1 (R 2; d c)). Any adversary who has advantage ɛ n G 3 can be drectly translated nto an IND-CPA adversary for the AEAD functon. For n > 1, we can terate ths sequence of games n tmes: G 0,1 = G 0,..., G 3,1 = G 3, G 0,2 = G 3,1,..., G 3,2,..., G 3,n. In a game G,j we replace the keys / PRFs nvolvng a c and b c j for some b. Therefore, f the advantage of any adversary n solvng DDH, PRF-IND, or IND-CPA s always neglgble, the advantage of any adversary n the full regstraton unlnkablty game wll be lkewse neglgble. Note that the game here provdes statc securty, wth the adversary declarng the users nvolved n the contact message ahead of tme. The proof can be extended to an adaptve adversary who declares the challenge users after seeng some of the users publc 11

12 G 0 G 1 G 2 G 3 G 4 K = PRF 2 H 3(g xc 1 ) (t j) R 1 R G 1 K R {0, 1} ν K R {0, 1} ν K R {0, 1} ν ID = H 0 (e (g 1, H 1 (t j ) xc )) K = PRF 2 ID = H 0 (e (g 1, H 1 (t j ) xc )) (t j ) ID = H 0 (e (g 1, H 1 (t j ) xc )) ( ) R 2 R G 2 C = AEAD 0 K (Dc) R 1 C = AEAD 0 ID = H 0 (e (g 1, H 1 (t j ) xc K )) (Dc) C = AEAD 0 K D )) 0 ID = H 0 (e (g 1, R 2 C = AEAD 0 K (Dc) C = AEAD 0 K (D 0) Fgure 5: Computng the challenge regstraton message (ID, C) n successve games for the short-term protocol. keys by, n each game, havng the challenger guess whch user wll be chosen for a c/a c and b c j and abortng f the guess was wrong, at the cost of the reducton no longer beng tght. Regstraton Unlnkablty of short-term protocol. We defne an unlnkablty game smlar to the prevous one. 1. The adversary supples the challenger wth: Two usernames, A 0 and A 1 Two peces of auxlary data, D 0, D 1 An epoch t j 2. The challenger generates secret keys x 0 and x The challenger flps a con to select a bt. 4. The challenger produces a regstraton message (ID, C) for user A c wth data D c, as shown n Fgure 5, game G The adversary may perform a polynomal number of queres Regster (, D, t j), whch wll result n a regstraton message produced by user A wth data D and epoch t j, as long as t j t j. 6. The adversary outputs ts guess for the bt c. We start wth G 0, where the challenger behaves as defned above, and make successve modfcatons to the computaton of the challenge message, as shown n Fgure 5. In G 1, we replace H 3(g xc 1 ) n the computaton of the challenge regstraton message wth a random number R 1. Note that an adversary A cannot dstngush between G 0 and G 1 unless t queres H 3 wth g xc 1 as the nput. If ths happens wth a non-neglgble probablty, we can construct an adversary A that wll solve the computatonal Co-Dffe-Hellman (co-cdh) problem [5] wth the same probablty. In the co-cdh game, we are gven h 2, h α 2 G 2 and h 1 G 1 and asked to produce h α 1. Our adversary A acts as a challenger for A, by followng the game G 1, settng g 1 = h 1. Instead of choosng x c explctly, t mplctly sets x c = α. Durng queres to the random oracle H 1(t k ), A chooses a random z k and returns H 1(t k ) = h z k 2. Therefore, whenever a regstraton message needs to be computed for A c, A computes H 1(t k ) xc as (h α 2 ) z k. Addtonally, for every query of H 3(w), A checks whether e(w, h 2) = e(g 1, h α 2 ). If so, then w = h α 1 = g xc 1 and t outputs t as the soluton for the co-cdh problem. In game G 2, we generate K randomly; snce n G 1 t s the output of a PRF wth a random key, dstngushng G 1 from G 2 wth a non-neglgble advantage produces an adversary wth the same advantage n the PRF-IND game. In game G 3, the challenger behaves as n G 2, but always supples D 0 to the AEAD encrypton n the challenge message. Any adversary that dstngushes between G 3 and G 2 wth advantage ɛ can be turned nto an adversary that wns the IND-CPA game for the AEAD functon wth the same advantage. Fnally, n game G 4, the challenger replaces H 1(t j) xc wth a random element of G 2. Any adversary who can dstngush between G 3 and G 4 can be turned nto an adversary who wns the DDH game n G 2: gven a DDH trple (g2 x, g y 2, gz 2) t sets H 1(t j) to g x 2 and H 1(t j) xc to g z 2. To be able to respond to regstraton queres for A c n other epochs, the challenger sets H(t j) = g r 2 for some random r, and uses (g y 2 )r for H(t j) xc. Note that n game G 4, the challenge message s computed ndependently of c, and hence the adversary can guess c correctly wth probablty at most 1/2. 12