PriFi: A Low-Latency Local-Area Anonymous Communication Network

10/27/2017 ∙ by Ludovic Barman, et al. ∙ 0

Popular anonymity protocols such as Tor provide low communication latency but are vulnerable to traffic-analysis attacks that can de-anonymize users. Traffic-analysis resistant protocols typically do not achieve low-latency communication (e.g., Dissent, Riffle), or are restricted to a specific type of traffic (e.g., Herd, Aqua). In this paper, we present PriFi, the first practical protocol for anonymous communication in local-area networks that is provably secure against traffic-analysis attacks, has a low communication latency, and is traffic agnostic. PriFi is based on Dining Cryptographer's networks, and uses a 3-layer architecture which removes the usual anonymization bottleneck seen in mix networks: packets sent by the clients follow their usual path, without any additional hop that would add latency. As a second contribution, we propose a novel technique for protecting against equivocation attacks, in which a malicious relay de-anonymizes clients by sending them different information. In PriFi's architecture, this is achieved without adding extra latency; in particular, clients do not need to gossip or run consensus among themselves. Finally, we describe a technique for detecting disruption (jamming) attacks by malicious clients and a blaming mechanism to enforce accountability against such attacks. We have fully implemented PriFi and evaluated its performance with well-known datasets. Our analysis is twofold: first, we show that our architecture tolerates well client churn; second, we show that the system can be used in practice with minimal latency overhead (e.g., 70ms for 50 clients), and is compatible with delay-sensitive application such as VoIP.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

Abstract

Organizational networks are highly vulnerable to traffic-analysis attacks that can infer information from their communications even if they are encrypted. We present PriFi, an anonymous communication protocol that is provably secure against traffic-analysis attacks, has low communication latency, and is application agnostic. PriFi builds on Dining Cryptographers networks and solves several issues of existing such networks. The communication latency is reduced via a client/relay/server architecture, where a set of servers assists the anonymization process without adding latency. Unlike mix networks and other DC-nets systems, client’s packets remain on their usual network path, without additional hop. PriFi protects clients against equivocation attacks with minimal latency overhead, without requiring communication between clients. PriFi also detects disruption (jamming) attacks without costly consensus among servers. We evaluate the practicality of PriFi in the context of a large, at-risk organization. Our results show that the system can be used with minimal latency overhead (ms for clients) and is compatible with delay-sensitive applications such as VoIP. In short, PriFI provides organizations with robust traffic-analysis resistance and maintains the Quality of Service of the communications.

1 Introduction

Local area networks (LANs) deployed in organizational networks are easy targets for eavesdropping by malicious or coerced insiders, curious administrators and endpoints compromised by malware. Even when the traffic is encrypted, the metadata usually remains visible, and a variety of traffic-analysis attacks – inferring sensitive information from traffic patterns – enables adversaries to gain information on the communication, such as the communication’s endpoints and the type, volume, and frequency of content exchanged. For example, traffic-analysis can be used to infer the words spoken by Skype users [4], their geo-location [33], and the visited websites from TLS and Tor traffic [41, 55, 54].

The risk of traffic-analysis attacks in organizational LANs becomes significantly worse for organizations that operate in adverse environments, such as diplomatic embassies and international humanitarian organizations. A recent study by Le Blond et al. [32] reveals that current secure communication mechanisms fail to meet the security requirements of a large humanitarian organization operating in areas of armed conflicts and other situations of violence. In particular, this study identified a need for traffic-analysis-resistant networks with sufficiently low-latency and high-bandwidth for conducting field work with no or acceptable overhead.

To protect against eavesdropping, some standard protocols encrypt the payload but usually do not protect the metadata (e.g., TLS, IPSec). Anonymous communication networks (ACNs) are tools designed to protect against traffic-analysis and metadata leakage, but they vary in the level of protection provided. Tor, the most widespread ACN, typically does not provide enough protection against traffic-analysis [54]. Some ACNs resist traffic-analysis at the cost of being application specific [30, 31], thus hindering user adoption. Dining Cryptographers networks (DC-nets) [5] provide provable traffic-analysis resistance, but existing systems introduce high latency, which restrains the applications they support.

We present PriFi, the first low-latency, traffic-analysis-resistant anonymous communication network tailored to organizational LANs, and its experimental evaluation in the context of the International Committee of the Red Cross (ICRC). Users connected to PriFi are assured that their communications are anonymous and indistinguishable from the communications of other users and devices in the LAN. PriFi provides this guarantee and ensures low-latency, traffic-agnostic communication (i.e., suitable for delay-sensitive applications such as streaming and VoIP) at the cost of a reasonably higher bandwidth usage in the LAN.

PriFi uses DC-nets [5] in a three-tier architecture composed of clients, a relay, and servers that are possibly geographically distributed in the Internet (Figure 1). Not only is this architecture naturally compatible with LANs, but it also allows PriFi to avoid a major latency overhead typically present in other DC-nets systems and mix networks. Unlike mix networks that fundamentally require multiple hops to achieve anonymity, which adds latency, the security of DC-nets does not depend on the number of hops; yet in practice, previous DC-net systems used multi-hop, multi-round protocols and costly server-to-server communications [9, 57, 10]. PriFi achieves significantly lower latency by removing all unneeded hops. For instance, clients’ traffic remains on its usual network path, without extra hops.

PriFi also presents techniques for protecting clients against two well-known attacks in DC-nets systems: equivocation attacks (i.e., de-anonymization by sending different information to different clients, and analyzing their subsequent behavior) and disruption attacks (i.e., jamming the communication channel by maliciously sending in every round). Equivocation attacks are trivially defeatable at high communication cost if clients gossip on the received information. PriFi achieves this without client-to-client communication and with minimal added latency via a novel technique in which clients encrypt their messages based on the history of the messages they have received so far. As a result, a cheating relay cannot decrypt client messages correctly and will be caught consequently. Disruption attack detection previously required many server-to-server communication to identify disruptors [57, 10]. In PriFi, this detection is done without adding latency or dedicated messages via a novel trap-bit mechanism that allows identifying and de-anonymizing the disruptors.

Figure 1: PriFi’s architecture made of clients, a relay, and servers. Clients packets remain on their usual network path, without going through the PriFi servers.

As a concrete motivating example of an organization operating in an adverse environment, we evaluate the performance of PriFi on a setup corresponding to the ICRC networks. We implemented a prototype of PriFi in Go, and evaluated its performance on the Deterlab [13] infrastructure. We gained the following key insights: First, PriFi scales sufficiently well with the number of users to accommodate a large percentage of ICRC delegations ( of the sites). Second, the latency overhead caused by PriFi is low enough for VoIP and video conferencing ( ms for 100 clients), and the internal and external bandwidth usage of PriFi is acceptable in an organizational network. Finally, with respect to the dataset used, user mobility is not problematic in preserving a high availability () of the PriFi network. To experimentally validate its capabilities, we are in the process of testing PriFi at the ICRC.

In summary, this paper makes five contributions:

  • PriFi, a retrofittable architecture to enhance organizational LANs with provable traffic-analysis resistance;

  • Novel low-latency protections against:

    • equivocation attacks by compromised relays;

    • disruption attacks by malicious clients;

  • An open-source, near-production level implementation of PriFi [1]; and

  • An experimental evaluation of the latency, bandwidth, and computational overhead of our implementation in the context of the ICRC.

2 Background

We illustrate in Section 2.1 the unique practical challenges that PriFi addresses in the context of our motivating at-risk organization, the International Committee of the Red Cross (ICRC), and we discuss how the related work on anonymity networks and DC-nets in particular, fall short in addressing them in Section 2.2 and Section 2.3, respectively.

2.1 Motivating Scenario

The ICRC is one of the largest and oldest humanitarian organizations in the world. With external offices (delegations) in more than 80 countries, the ICRC humanitarian mission is to protect and provide assistance to the victims of armed conflicts and situations of violence.

The ICRC, as well as other humanitarian organizations, has adopted technologies such as mobile phones, digital records, and electronic transfers to improve their operations and services offered. However, such technologies open the door to new threats that can be exploited by other entities. The ICRC and other humanitarian organizations have been the target of numerous attacks that threaten not only the safety of vulnerable people and humanitarian workers, but also the neutrality of humanitarian actions [22]. For instance, researchers found that humanitarian workers might have been targeted by zero-day exploits similar to the ones targeting a well-known Middle East political dissident [35].

Given this unique threat model, it is clear that the ICRC requires robust mechanisms to protect its communications from traffic-analysis attacks and that current technologies fail to fulfill such needs [32]. Moreover, traffic-analysis resistance solutions should take into account ICRC’s practical factors such as physical security and coercion resistance.

We use the ICRC scenario as a motivating example for the need of a practical anonymous communication network to be robust against traffic-analysis attacks more than current alternatives and to provide adequate quality of service, i.e., low latency. In Section 8, we present more details about ICRC’s organizational structure and communication network, and how our proposed mechanism, PriFi, fulfills the security needs of the ICRC.

2.2 Related Work

One way to protect against local eavesdroppers is by tunneling the traffic through a VPN; due to their low latency, VPNs can support most network protocols. Although convenient, VPNs offer limited eavesdropping protection: the VPN provider could be coerced or compromised, and a powerful adversary could break a user’s anonymity based on traffic-analysis attacks. As a result, this solution is often regarded as insufficient, and a significant number of solutions have been proposed to provide stronger privacy and security [49]:

For stronger anonymity protection without a single point of failure, several efforts rely on mix networks [6, 12, 45, 36, 15, 47]. However, those systems usually provide small anonymity sets, as they are generally less convenient due to their high latency. Moreover, several attacks are able to break their anonymity guarantees [42, 40]. To achieve traffic-analysis resistance, recent solutions use several servers and multiple traffic hops [44].

Solutions based on onion routing [14, 7, 37] tend to be more popular due to their low latency: Tor [14], the most widely deployed anonymous routing protocol, reports anonymity sets in the order of millions of users. However, Tor and similar protocols are often vulnerable to traffic-analysis attacks and often do not protect against global adversaries [38, 21, 55, 24, 26]. Hence, the above low-latency efforts (e.g., Tor) offer a large but weak anonymity set.

Some solutions provide strong anonymity guarantees and high scalability, by using techniques such as differential privacy [53], private information retrieval [28, 8] and secure multi-party computation [8, 27]. However, these solutions are designed for specific applications, such as file sharing [31, 18], VoIP [30] and messaging/microblogging [8, 28, 53, 29, 27]. This requires the end users to select one specific solution for each situation, which arguably hinders both the adoption and strength of the provided anonymity.

Finally, Dining Cryptographer’s networks (DC-nets) [5] provide anonymous communication with provable traffic-analysis resistance. Aside from the original design, DC-nets have been re-used in several anonymous communication networks [9, 57, 10] and have been extensively studied [19, 52, 20, 17, 16, 25]. Theoretically, DC-nets systems are attractive due to their provable security that doesn’t depend on forwarding messages through a set of servers, and because they are in principle parallelizable; but, existing DC-nets usually have high latency and bandwidth overheads. Dissent [9, 57] partially addresses these limitations of group-communication scenarios (e.g., mesh network), but only achieves latency in the order of seconds, mostly due to the number of client-to-server and server-to-server messages required. PriFi reduces communications required by using a three-layer topology and exploiting (W)LANs characteristics, achieving a significantly lower latency.

2.3 DC-nets Challenges

Impact of Topology. The initial DC-nets design [5] requires a shared secret between every pair of members, which can be seen as a flat topology (only made of clients). Dissent in Numbers [57] and subsequent work [10] have a more scalable two-tier topology made of clients and servers, where each client only exchanges a secret with each server but not with other clients. Although this architecture has several benefits (e.g.,  reducing the total number of keys), it has a major negative impact on latency: it requires several server-to-server rounds of communication to handle client churn, to maintain integrity of messages, and to ensure accountability of participants.

Churn Handling. DC-nets have a particular relationship with churn, i.e., clients joining or leaving the network. Unlike other anonymity networks, the disconnection of any client invalidates the current communication and forces re-transmission of the data. This is inherent to the design of the protocol: in the phase of reconstructing a plaintext message using ciphertexts from all nodes, a single missing ciphertext prevents the recovery of . This is a fundamental limitation of DC-nets and cannot be easily removed. Dissent in Numbers [57] proposes a solution to eliminate the cost of churn when a client disconnects, however, it requires coordination among a set of servers, which can be costly if the servers are in different jurisdictions (which is often desirable for coercion resistance).

Disruption Protection. DC-nets are known to be vulnerable to disruption attacks (i.e., jamming) [5] from malicious insiders, because their encrypted messages are malleable and an adversary on the network can flip bits in other clients’ plaintexts. Different solutions have been proposed: both Dissent [9] and Verdict [10] have proactively verifiable constructions that prove the correctness of the ciphers, whereas Dissent in Numbers [57] describes a blame mechanism to retroactively find and exclude a disruptor. These disruption protection mechanisms, however, have significant performance costs: Dissent in Numbers uses a costly shuffle that requires several server-to-server communications, and the verifiable DC-net used in Verdict [10] is computationally intensive, and hence, does not allow frequent communication rounds.

Scheduling. A DC-net creates an anonymous channel shared between its clients. If many clients try to transmit at the same time, collisions will occur. As retransmissions are usually costly, previous work [9, 57, 10] use a scheduling mechanism to prevent honest clients from sending messages at the same time. Dissent [9] relies on an internal shuffle mechanism that divides the client ciphers into slots. Dissent in Numbers [57] and Verdict [10] use a Neff-Shuffle [39] to organize clients into time slots. PriFi uses a similar schedule; a particularity of such scheduling shuffle is that the mapping between clients and slots must remain secret (clients only recognize their own position in the schedule) to preserve anonymity.

Equivocation. In system that achieve receiver-anonymity using broadcast, when an untrusted party is responsible for relaying information to anonymous clients, it may perpetrate an equivocation attack by sending different clients different information. In this attack, the adversary tries to de-anonymize clients by analyzing their reaction to the (different) information they have received. A concrete example of equivocation is provided in the Appendix A.

3 PriFi System Overview

3.1 Goals

PriFi’s design is based on the following goals:

(G1) Anonymity

: An adversary should not be able to guess users’ identities or attribute an honest user’s message to its author with a probability significantly better than random guessing.

(G2) Traffic-analysis resistance: PriFi should not leak information that could help an adversary to break the anonymity of honest users. In particular, an eavesdropper should not be able to tell whether a particular client is transmitting/receiving or not, i.e., local sender and receiver unobservability.

(G3) Low-latency: The delay introduced by PriFi should be small enough to support network applications with different QoS requirements, e.g., e-mail, instant messaging, web browsing, VoIP and videoconferencing.

(G4) Scalability: PriFi should support small to medium organizations (i.e., up to a few hundred users), such the ICRC delegations.

(G5) Accountability: Misbehaving parties should be traceable without affecting the anonymity of honest users, and with a moderate performance impact.

3.2 System Model

Consider a set of clients (or users) who want to make use of the Internet while benefiting from anonymity and traffic-analysis resistance. The clients are part of a LAN, and more precisely they are connected to a relay; typically, the relay is a router or switch, and is already part of the existing infrastructure. The relay can process regular network traffic in addition to running our protocol; hence, PriFi can be added to a network without disruption.

Outside the local-area network, there is a small set of  servers whose role is to assist the relay in the anonymization process. In the ICRC case, each delegation has a server in a secure room that fits this role; in other deployments, these servers could be maintained by independent third parties, similar to the Tor’s volunteer relays, or sold as a “privacy service” by companies. In all cases, to maximize diversity and collective trustworthiness, these servers are distributed around the world, preferably across different jurisdictions. Therefore, the connections between the servers and the relay are modeled as high latency. Finally, we define downstream communication as the data from the Internet to one of the clients, and upstream communication as the data from one of the clients towards the Internet. This setup is summarized in Figure 1.

Usability. From the point of view of a client who is using the organization’s PriFi network to communicate with other members or the Internet, PriFi can be considered as a low-latency proxy service (which resists traffic-analysis attacks): it receives data from and sends data to the applications running on the user’s computer. The relay acts as the other end of the proxy, relaying data between the Internet and the clients. However, unlike traditional proxy services, the relay is not trusted; it might maliciously (possibly by colluding with other untrusted entities) attempt to de-anonymize the clients.

3.3 Threat Model

We say a node (client, server or relay) is honest if it follows the protocol faithfully and does not collude or leak sensitive information to any other node. A node controlled by the adversary is malicious (or dishonest); malicious nodes can deviate arbitrarily from the protocol and can collude with each other to de-anonymize honest clients and disrupt the communication. In our model, clients can be malicious, but we require at least two honest clients (otherwise, de-anonymization is trivial).

The relay can be malicious, i.e., it might actively try to de-anonymize honest users or perform almost any attack with one exception: it will not perform actions that affect the availability of PriFi communications such as delaying, corrupting or dropping messages. In our scenario, the relay is the gateway to the Internet (e.g., a WLAN router on which PriFi runs). A malicious relay/router could perform attacks against availability on any traffic anyway (e.g., simply drop all packets), and PriFi does not make the situation any different. We emphasize that we do not consider the clients nor every server trusted for availability; in particular, malicious clients and servers can conduct disruption attacks in which they jam the communication channel by sending invalid messages, but the relay will not. Finally, we argue those attacks by the relay would not have a lasting effect anyway: by definition, such attacks against availability can be easily detected by clients, and would cause them to take administrative actions (e.g., report to a network administrator) and/or to switch to a more reliable relay.

The servers follow the widely-adopted anytrust model [57, 53, 56]. In short, at least one server is honest (but there is no need to know which one), and they are all highly available. As such, the number of servers is a security parameter than can be tuned depending on the application. As usual, malicious servers can try to de-anonymize honest clients or perform disruption attacks.

We assume that the servers and the relay are protected against external DoS attacks through well-known defense mechanisms such as server provisioning or proofs-of-work. Such attacks are common to any distributed system and therefore not addressed in PriFi. In addition, we assume that all nodes communicate using non-private but authenticated channels; the adversary can observe all messages when in transit. End-to-end content privacy can be achieved via orthogonal, well-understood content encryption mechanisms such as TLS. Moreover, assume that asymmetric and symmetric key encryption algorithms, key-exchange schemes, signature schemes, and hash functions are all correctly implemented and configured. Finally, we assume that there is a public-key infrastructure (PKI) in place to authenticate participants.

4 Basic PriFi Protocol

In this section, we present a simplified version of the PriFi protocol, which does not address equivocation attacks nor disruptions attacks. We explain how to extend this protocol to handle disruption and equivocation attacks in Sections 5 and 6, respectively.

4.1 General Concepts

Overview. PriFi uses a DC-nets protocol as anonymization primitive. Participating nodes (clients and servers) send cryptographic material every time slots, in which is produced one anonymized message. Every slot, exactly one client – defined by a schedule – gets to transmit a message.

Description. The protocol is executed jointly by the clients, servers, and the relay to anonymize messages sent by the clients to the Internet. The protocol proceeds in time slots such that only one client – the slot owner – is allowed to send an -bit anonymous message to the Internet in each time slot. A schedule consists of ordered time slots, each corresponding to one of the clients; each client has the opportunity to send an -bit message exactly once during a schedule. An epoch is the timespan where the configuration (i.e.,

shared secrets and schedule) does not change. At the beginning of each epoch, a new schedule is established. Epochs expire after a predetermined period of time (

e.g., 10 minutes) to prevent clients from using the same slot for an extended period, thus reducing the chances of adversary linking upstream messages to a particular slot. Epochs can also expire due to network churn, e.g., clients connecting or disconnecting from the system. Figure 2 illustrates these concepts.

Figure 2: Illustration of time slots, schedules and epochs for clients . The labels show the slot owners.

PriFi uses DC-net-based anonymization only for the upstream traffic. To anonymize the downstream traffic, the relay encrypts each downstream message with the ephemeral public key of the receiver (generated during the Set-up phase described next). The relay then broadcasts the encrypted downstream message to all clients, achieving receiver anonymity. Only the intended recipient is able to decrypt the downstream message, and in particular the relay does not know for which user he encrypts.

Finally, PriFi is a closed-membership system meaning that each client and each server holds a public/private key pair before the protocol starts, and that the relay holds a roster of all the public keys. This enables the relay to verify the membership of the clients. To protect against intersection attacks, membership can be proven in zero-knowledge (Section 7).

4.2 Protocol Phases

The PriFi protocol consists of four main phases:

Setup Phase. In this phase, the relay first authenticates all clients using their public keys. Then, each client runs a key exchange protocol with each server to agree on a shared secret , which is only known to both of them. This secret is later used to seed a pseudorandom generator (PRG) to obtain a stream of pseudorandom bits, the pads, from which the clients and the servers will compute their ciphertexts. Using this approach, clients and servers do not need to generate a shared secret for every slot. Figure 3

illustrates the relationship between shared secrets, pads and ciphertexts for a client

.

Figure 3: Relationship between shared secrets, pads, ciphertext. Pads and ciphertexts also depends on the Anonymize round .

Schedule Phase. After setup, all nodes (clients, servers and the relay) jointly perform a Schedule phase to assign one client to one slot. Note that this binding must remain secret, otherwise there would be no anonymity. Our protocol outputs a schedule where each client can recognize its own slot, but not the slot of other clients.

First, each client generates an ephemeral public/private key pair. Second, the relay collects all the clients’ ephemeral public keys as a sequence . Third, all the servers sequentially shuffle using a verifiable shuffle protocol [39], each one sending its result and proof to the next server via the relay. Finally, after the last server finishes running its verifiable shuffle protocol, the relay holds a random permutation consisting of fresh pseudonyms for the public keys in ; represents the schedule, as it indicates when clients can send upstream data, i.e., their slot. A client can recognize its own pseudonym by using its ephemeral private key, but other parties cannot link an ephemeral public key to a fresh pseudonym.

Anonymize Phase. After the Schedule phase, all nodes continuously run the Anonymize protocol (see Protocol 1). This protocol occurs in rounds; one round (or instance) of the Anonymize protocol corresponds to one slot in the schedule.

In each round, all servers compute one ciphertext and send it to the relay. Each server ciphertext is an XOR of pseudorandom -bits pads generated using a PRG seeded with the shared secret of each client. Likewise, each client computes an -bits ciphertext, computed as the XOR of pads, and sends it to the relay. The client owning the slot creates a slightly different ciphertext: in addition to XORing the pads, the slot owner also XORs its -bits upstream message . In practice, is an IP packet without source address. If the slot owner has nothing to transmit, it sets .

Once the relay receives the ciphertexts from all clients and servers, it XORs them together to obtain . If the protocol is executed correctly, should be equal to , as all pads are included exactly twice.111One notable exception: if the round was disrupted, discussed in Section 5. If is a full (and valid) IP packet, the relay forwards it to its Internet destination (with the relay’s IP address as the source address, i.e., the relay act as a proxy). If it is a partial packet, the relay buffers it, and completes it during the next schedule.

At this point, the relay has computed exactly one upstream message , and possibly sent it to its Internet destination. To complete the current round of the Anonymize phase, the relay broadcasts one downstream message to all clients, being whatever data the relay needs to send to the client: either an immediate answer to , or an answer to a previous upstream message . The relay uses UDP broadcast rather than unicast sending, letting Tier-2 network equipment (e.g., switches) replicate the message if needed; in WLANs, the broadcast is achieved in only one message, achieving receiver anonymity at no cost. Finally, is of arbitrary length, and in particular can be much bigger than , easily accommodating downstream-intensive scenarios.

In short, a round of Anonymize consists of exactly one exchange among all clients and the relay ( client ciphertexts upstream, yielding one upstream message , and one downstream message ). Hence, the clients are in lockstep and remain synchronized with the relay.

Notations: Let denote the clients, denotes the relay, denote the servers, and denotes the bit-length of ciphertexts sent by clients and servers to the relay in each time slot.

1. Server Ciphertext Generation. Each server computes an -bit pseudorandom pad for each client using a PRG seeded with . The server then computes its ciphertext from

and sends it to ;

2. Client Ciphertext Generation. Each client performs the following steps:

  1. [label=.]

  2. Generate a -bit pseudorandom pad for each server using a PRG seeded with

  3. Let denote the permutation generated by the Schedule phase, and denote ’s next bits of data. Compute and send a ciphertext to such that

    • if (i.e.,   is the slot owner), then

    • Otherwise,

3. Plaintext Reveal. collects the ciphertexts from the servers and from the clients and computes

sends to the Internet.

4. Message Broadcast. broadcasts a downstream message to each . If has no data for any client, is a -bit message.

Protocol 1 Anonymize phase for a given round

Resynchronization Phase. In the case of churn, e.g., if any client or server disconnects, or a new client requests to join the PriFi network, the relay broadcasts a Set-up request to all nodes. Upon reception, each node finishes the current Anonymize round, and re-runs both the Set-up and Schedule phases. A resynchronization signals the start of a new epoch. Network churn can significantly affect performance, which is a well-known problem for DC-nets-based protocols: we propose optimizations to address this concern (Subsection 4.4).

4.3 Practical Considerations

Servers Latency. Servers should be located in various jurisdictions to reduce the risk of coercion by authorities; this implies large latencies between them and to the relay (e.g., ms). In other systems (e.g., Tor [14], mix networks and other DC-net systems [9, 57]), this is a major latency bottleneck, which is avoided in PriFi.

In PriFi, the anonymized data does not go through the servers. Instead, the servers send cryptographic material to the relay, where it is combined with the client’s ciphertexts. Servers’ ciphertexts are computed by XORing pseudorandom pads seeded with the secret each server shares with each client. This operation is independent of the communicated content; hence, servers can compute and send ciphertexts ahead of time, well before they are needed by the relay. The ciphertexts are then buffered by the relay, until needed by an Anonymize round. This approach also reduces the effect of the jitter on the network path between the servers and the relay. Assuming high-throughput links between the servers and the relay, the duration of the Anonymize protocol does not depends on the servers’ latency to the relay.

Slow Servers. Servers are chosen during the set up of the relay and can be replaced at the end of every epoch. Any slow server (e.g., server with poor connection to the relay) can be excluded from the set of servers to preserve QoS.

Relay Overhead. In terms of storage, the relay does not have to buffer server ciphertexts for each future round: it can XOR them in advance as well, only storing one -bit ciphertext per future round. A simple throttling mechanism can control servers’ throughput to avoid overflowing the relay’s buffer. Finally, in this basic version of the protocol, the relay’s only cryptographic operation is a XOR; we argue that the CPU cost is bearable even on moderately-provisioned relays.

End-to-End Privacy. The current protocol broadcasts the downstream messages to achieve receiver anonymity; if the downstream message is plaintext, any client could see what other clients receive. A simple solution is to encrypt the downstream content using the ephemeral keys in . We emphasize that the relay does not know to which client each key in belongs to.

4.4 Client Churn

Client churn can have a significant effect on the performance of DC-net-based protocols, including PriFi. For example, the disconnection of a single client invalidates all the ciphertexts in the current round. We define two types of client churn: (1) Graceful disconnections, where clients gracefully announce to the relay their intent to connect or disconnect from PriFi; and (2) Abrupt disconnections, where clients abruptly disconnect from PriFi without sending any warning to the relay.

PriFi employs a delay-and-reconfiguration approach to handle graceful churn without communication disruption. The key idea is to execute the resynchronization phase, triggered by a client gracefully connecting or disconnecting, in parallel to the current Anonymize phase, thus maintaining the communications. That is, the joining or disconnecting client sends a request to the relay, which starts in background a new Setup and Schedule phases with the new set of clients , while maintaining the current Anonymize phase with the old set . Once each client of starts the new Anonymize phase (hence, clients in both sets run two concurrent Anonymize protocols), the relay stops the old Anonymize phase concerning . In the case of abrupt disconnections, if a client disconnects unexpectedly, it disrupts the current Anonymize round, and the upstream message is lost. The delay-and-reconfiguration approach is not applicable in this scenario: all nodes need to stop, and perform a new Set-up and Schedule phase. In PriFi, this is the only event when the communications stop. We evaluate the effect of client mobility and churn in more detail in Subsection 8.3.

4.5 Anonymous Authentication

Even if an adversary cannot directly link messages to a client, it can run intersection attacks by monitoring the set of online clients/devices, and correlate it with the anonymous message sent. This scenario is especially plausible in the case of members of an organization identifying themselves to access the network. To solve this problem, PriFi uses the Deniable Anonymous Group Authentication (DAGA) [50] protocol, an anonymous authentication mechanism. During authentication, members prove that they own a private key that corresponds to one of the group public keys, without revealing which one. Other alternatives could fit PriFi [34, 46], but DAGA has the benefit of providing deniable anonymous authentication, further protecting clients from coercion.

5 Disruption Protection

A weakness in our basic PriFi design is that a single malicious member can anonymously jam communications, either completely or selectively. We refer to this as the disruption attack. In a typical disruption attack, a malicious PriFi client or server can transmit arbitrary bits – instead of the value defined by the protocol – to corrupt the upstream messages of other clients without leaving a trace. In the related work, those attacks are detected using trap protocols [5], or costly shuffles before every DC-net round [9] or before transmitting accusations [57]. All existing solution require several dedicated message exchanges even to identify the presence of a disruptor, which adds latency. In PriFi, we introduce a protection against disruption attacks that does not require additional messages, nor adds latency.

We now improve the protocol presented in Section 4 to resist against disruption attacks.

Attack Detection. During the Schedule phase (see Section 4), the relay establishes an additional shared secret with each client. The client owning the current slot uses this shared secret to compute the HMAC of the upstream message, HMAC. Next, the client sends the upstream message and its HMAC to the relay. The relay validates the HMAC to find evidence of a disruption attack. If the validation fails, the relay indicates, via the downstream message, that a disruption has been detected and that, in the same slot of the next schedule, a verifiable DC-net [10] should be used to prevent further message corruption (for performance reasons, the relay could wait for a few schedules before requesting the use of a verifiable DC-net). Note that, by letting the relay detect disruption attacks, we remove the work and responsibility from clients. This is possible because the relay is trusted for availability (see Section 3), i.e., the relay will not perform attacks to reduce availability; as argued before, this would be quickly noticed by the clients anyway, who can take administrative actions.

Identifying Flipped Bits. Only one flipped bit is needed to identify and exclude the malicious client or server. More precisely, the relay needs to find a bit that was in the original message but got flipped to (using a bit that was and got flipped to leaks information about the slot owner). For this purpose, the affected client will resend the original upstream message in her next slot, which is now using a verifiable DC-net to prevent further disruption. The relay compares the original and corrupted upstream messages to find a flipped 0-bit.

If a flipped 0-bit is found at position , the relay will stop the communications (i.e., the Anonymize protocol) and send a signed request to all clients and servers to reveal the individual bits from their different pseudorandom pads at position for the disrupted round; each client will reveal one bit per server, and each server will reveal one bit per client.

If no flipped 0-bit is found, the relay stops the disruption protection protocol and communications are not interrupted, i.e., the attack is detected, but the disruptor cannot be traced without breaking anonymity guarantees. To reduce the chances of a disruptor flipping only 1-bits (e.g., the adversary could guess parts of the content in the upstream message), the client could additionally XOR the upstream message with the shared secret , which ensures that the adversary has only chance of flipping a 1-bit.

Identifying Disruptor. Once the relay receives all the bit-revealing messages, it proceeds to check if a client or server revealed values that do not match with the value sent in the bit position during the disrupted round, i.e., if a client or server is blatantly lying during the disruption-protection protocol. If the values do not match, the corresponding client or server is the disruptor and is excluded from the system. If no mismatch is found, the relay proceeds to compare the bits revealed by the clients with the bits revealed by the servers. There must be, without loss of generality, a difference among one of the bits that one of the clients and one of the servers revealed (otherwise, the round was not disrupted). After identifying a mismatch between a client and server, the relay requests that they reveal their shared secret , along with a zero-knowledge proof showing that it was computed correctly. The relay verifies the proofs and seeds the PRNG with the secrets to generate the pad for the disrupted round. At this point, the relay will be able to determine which one, the client or the server, disrupted the round and exclude it from the system. Revealing the shared secrets does not compromise anonymity, as it never happens between two honest parties.

6 Equivocation Protection

Another important challenge introduced by the PriFi architecture is: a malicious relay can equivocate by sending different downstream messages to different clients to de-anonymize them. For example, in an unencrypted communication (e.g., a DNS request), the relay can slightly modify the downstream message for each client. These unique messages might affect the messages sent in subsequent rounds (e.g., the contacted IP in the case of a DNS request), so the relay might be able to determine which client sent the request, based on their subsequent behavior. A concrete example is provided in Appendix A. As PriFi uses a fixed schedule during a given epoch, de-anonymizing one slot is enough to de-anonymize a slot owner for the whole epoch. In the next subsection, we alter the protocol presented in Sections 4 and 5 to add a protection against equivocation.

6.1 Protocol Overview

PriFi protects against relay equivocation attacks without adding extra latency, and without synchronization between clients. This is achieved by encrypting clients’ upstream messages in such a way that the resulting ciphertexts depend on the history of downstream messages in a epoch. As a result, the relay can only decrypt an upstream message if all clients agree on the downstream messages they have received in the current epoch. If the clients disagree, the relay will not be able to decrypt the upstream message from the current and future rounds.

High-level description. The protocol works as follows. In each round, the slot owner encrypts its upstream message with a fresh random key and includes a blinded version of this key in its upstream message. The key is blinded with a value computed by raising the downstream history value to a secret exponent derived from the client’s pads. The downstream history consists of the cryptographic hash of the previous downstream history concatenated with the most recent downstream message, hence, it depends on all past downstream messages. Moreover, the downstream history is “bound” to the client’s pads via exponentiation in a cyclic group, where the discrete logarithm problem (DLP) and the decisional Diffie-Hellman assumption (DDH) hold. Other clients also send contributions and, if all clients have similar downstream history, the relay will be able to unblind the key and decrypt the upstream message. When new clients join the system, the relay provides them with the current downstream history value during the setup phase. The downstream history is reset by the relay via a reset-history command broadcasted to all clients; thus, the downstream history is kept across epochs. We argue that since attempting an equivocation attack blocks further communications (disrupting availability - which the relay is trusted not to do in the first place) and ultimately forces the issue of a visible reset-history command to all clients, the relay had no incentive to attempt such attack. Additionally, clients receiving such command should make sure to discard and re-query any information recently received from the relay.

6.2 Protocol Description

Protocols 2, 3 and 4 are run by each node as part of the Anonymize phase (see Protocol 1 in Section 4) for equivocation protection.

Let denote a finite field of prime order , denote a multiplicative group of order with generator such that the DLP and the DDH assumptions hold in  [3]. Also, let denote the message that client wants to send to the relay. Let be a cryptographic hash function, and and be publicly-known one-to-one functions that are efficiently computable and invertible.

Consider servers, clients and a client with a plaintext and an empty downstream history .

  1. [label=(0)]

  2. Upon receiving a downstream message from the relay, sets .

  3. If is the slot owner, it picks a pseudorandom key , sets and sends to the relay, where

    (1)

    (’s are the pads already defined in Protocol 1)

  4. If is not the slot owner, then it sets

    (2)

    and sends to the relay.

Protocol 2 Equivocation Protection – Client

Each server sends to the relay, where

(3)
Protocol 3 Equivocation Protection – Server

The relay starts with an empty downstream history denoted by .

  1. [label=(0)]

  2. Upon receiving a downstream message for the clients, the relay sets .

  3. Upon receiving ’s from all clients and ’s from all servers, the relay decrypts the owner’s message from:

    (4)
  4. The relay sends to the corresponding Internet address.

Protocol 4 Equivocation Protection – Relay

Due to space constraints, we discuss in Appendix A how we prevent malicious parties from abusing the equivocation protection protocol.

7 Supporting Different QoS Levels

To support different QoS levels, PriFi enables clients to subscribe to channels with different bitrates. Each channel is an isolated instance of the PriFi protocol, but runs with different speeds and payload sizes. In this way, constrained devices (e.g., suitable IoT devices, battery-powered devices) only join “slow” PriFi channels that require little computation, while more powerful devices join both slower and faster channels. Channels correspond to categories of traffic, for instance “e-mails”, “web browsing”, “VoIP” and “video conferencing”. With this approach, a device that has no VoIP capabilities can save resources by joining only the appropriate channel.

Devices connected to several channels participate in the anonymity set of those channels, but probably only communicate using the fastest. The benefit for this approach is increasing the anonymity set of slower channel. The cost of being active in several channel is estimated as follow: assuming an order of magnitude difference in terms of latency between channels (

e.g., web browsing at ms, VoIP at ms latency), joining an additional slower channel only adds message every messages on the fast channel, a tolerable cost for high-end devices.

This approach causes a well-known tension between anonymity and performance. That is, having all devices in one anonymity set provides better anonymity, yet might be completely impractical for a whole class of devices (e.g., battery-powered smartphones). Hence, we propose to accommodate more devices by splitting the anonymity set in parts. The size of the partitions, the number of channels and their parameters are highly dependent on the security needed, the number of active devices and their requirements; finding the appropriate balance is outside the scope of this work.

8 Evaluation

Figure 4: Topology of the ICRC network. Delegations contain one or more physical facilities called sites. One or more (W)LANs is deployed at each site.
Figure 5: Repartition of users per ICRC site. of sites have less than users.

We implemented PriFi in Go [1]. As a motivating example, we evaluate the deployment of PriFi in the ICRC sites; we emphasize that this setup is similar to most organizational networks and not specific to the ICRC. In each site, users are connected to the Internet through a (W)LAN, and there is a server room where the PriFi relay is deployed. A summary of the ICRC topology is presented in Figure 4.

Methodology. As a preliminary approach, the setup is tested on an equivalent Deterlab [13] deployment. Our evaluation is fourfold: first, we measure the end-to-end latency through SOCKS without data, by having client randomly send pings to themselves. Second, we replay PCAP files corresponding to various workloads on PriFi, and measure the added latency and the bandwidth usage. Then, we compare PriFi with the closest related work, Dissent in Numbers [57]. Finally, we explore the effect of churn and user mobility to DC-net systems.

Reproducibility.

All experiments presented in this paper are reproducible with a few simple commands after cloning the repository [1], e.g., ./prifi.sh simul-vary-nclients. Additionally, all raw logs and scripts to recreate the plots are available in a separate repository [2].

8.1 Performance Evaluation

Setup. The topology simulated in Deterlab consists in a Mbps LAN with ms latency between the relay and the clients; we run servers, which each have a Mbps link with ms latency to the relay. We use machines, dedicated to the relay and per server; clients are simulated over the remaining machines. All machines are GHz Xeon Dual Core with GB of RAM. We focus our evaluation for users, as only a small fraction of ICRC sites have more than users (Figure 5).

(a) End-to-end latency of PriFi, experienced by one client, without pipelining. A significant part of this latency comes from the scheduling mechanism used.
(b) Effect of pipelining on latency. A window divides the latency by in comparison to the naïve approach.
Figure 6: End-to-end latency experiments. Clients randomly send pings to themselves.

End-to-End Latency. Figure 6(a) shows the latency of the PriFi system, i.e., the time needed for an anonymized packet to be sent by the client, decoded by the relay, and sent back to this same client. In this experiment, one random user is responsible for measuring those “pings”, while others only participate in the protocol without sending data (i.e., the number of active user is , anonymous among all users). The latency increases linearly, from ms for users (e.g., a small company) to ms for users, and scales reasonably with the number of clients. A major component of the latency is the buffering of messages by the clients; having only one slot per schedule, clients must wait this slot before transmitting data. This waiting time is depicted by the red curve in Figure 6(a). To reduce the time spent waiting on the slot, we alter the scheduling mechanism and allows slots to be closed. A periodic reservation map allow clients to anonymously specify if they want to send data; if not, the round is defined as closed. The relay skips closed rounds, which allows for shorter, more frequent schedules. For instance, if only one user wants to transmit, the relay alternates between reservation map and -slot schedules. This reservation mechanism improves the situation where many users are idle. It induces additional delay in some cases, as the client needs to wait for the next reservation to open his slot, and wait again for his slot. Other scheduling mechanisms (e.g., embedded in each packet, or no schedule but allowing collisions) would yield different trade-offs between latency and number of users depending on their workload; finding the best way to divide the anonymous channel is out-of-scope of this project. Finally, Figure 6(b) also demonstrates how pipelining (parallelizing DC-net rounds) can reduce latency in lock-step protocols like PriFi.

Replaying PCAPs. We then evaluate the performance of PriFi when replaying real traces. Using the same setup as before, of the clients are randomly assigned .pcap files from a pool, and after a random delay , replay the individual packets through PriFi. The relay decodes the packets and records the time difference between the decoded packet and the original trace (due to the fact that most endpoints present in the traces were not reachable anymore, the recorded latency does not include the communication to the Internet endpoints, but only the added latency by PriFi).

Datasets. We use the dataset ‘apptrafictraces’ [48] from CRAWDAD, which contains the traces for several applications. We selected three traces: a ‘Skype’ trace where one client performs a VoIP (non-video) call for seconds; a ‘Hangouts’ where one client performs a video call for seconds; and an ‘Others’ trace where “Gmail, Facebook, WhatsApp, Dropbox and others” non-audio, non-video services where running for minutes.

(a) Additional latency experienced by clients
(b) PriFi bandwidth usage. Every client and server is sending data at the ”DC-net bitrate”.
Figure 7: PriFi performance when of the users perform a Skype call.
(a) of users performing various HTTP(S) requests and file downloads.
(b) of users performing a Google Hangout video call.
Figure 8: PriFi latency with the ‘Others’ and ‘Hangouts’ dataset. The bandwidth usage in both cases is similar to the one observed in Figure 7(b).

Analysis. Figures 7(a)8(a), and 8(b) show the added latency on the ‘Skype’, ‘Others’ and ‘Hangouts’ dataset, respectively; Figure 7(b) shows the bandwidth used (PriFi had similar bandwidth usage for all three dataset). The latency increases with the number of clients, which is due to (1) the increasing traffic load going through PriFi, as more users send data, and (2) to the increasing time needed to collect all clients ciphers. In Figure 7(b), all clients and servers have to exactly match the DC-net bit rate; hence, the bandwidth usage on the LAN is times the DC-net bitrate. The total incoming traffic from the Internet (the sum of the traffic from the servers) is depicted with green boxes. In Figure 7(b), the decreasing bandwidth usage w.r.t to the number of clients indicates that PriFi spends more time waiting and less time transmitting; this is again due to the increasing time spent waiting for client ciphers. This is hardly desirable, as it means that overall PriFi cannot fully utilize the available bandwidth to offer minimal latency; this could be mitigated by increasing the pipelining of rounds for slow clients, or clients with high jitter, so that all clients answer in a timely fashion; this has however not been experimented.

We draw the following insights: first, the mean added latency in the case of a Skype call is below ms for up to clients, and below ms for clients. The International Telecommunication Union estimated the call quality starts degrading after a ms one-way latency increase [51], and users start noticing a degraded quality after a ms one-way latency increase [23]. Hence, while the current implementation starts to struggle with clients, it supports VoIP calls for 0-80 users. Second, the mean added latency in the case of the ‘Others’ dataset is always below ms, which seems acceptable for Web and background services; as a rough estimate, website pages usually load in seconds. Finally, the replay of the ‘Hangouts’ data exhibits similar behavior as the ‘Skype’ dataset; we see that the latency increases reasonably until users, but then drastically increases, meaning that the current implementation cannot transmit the data fast enough, and that buffering occurs at the clients.

8.2 Comparison with Related Work

The closest related work is Dissent In Number (D) [57]; like PriFi, it provides provable traffic-analysis by using DC-nets, has similar assumptions ( anytrust servers) but with no particular emphasis on being low-latency. In D, the topology is only made of clients and servers, and DC-net rounds happen less frequently due to several server-to-server exchanges during one round, which are avoided in PriFi.

Despite our efforts (and attempts at patching the code), we have been unable to fully evaluate D: when run on a Deterlab topology similar to PriFi (with servers at ms latency from the clients) and similar to the original topology described in the D paper, no communication happened for more than clients (Appendix, Figure 11). Hence, to provide a basis for the comparison, we analyze the number of messages in one round. In D, clients send their ciphertext directly to the servers. At the end of the pre-determined epoch, in the Inventory phase, the servers gossip among themselves and determine which clients have participated; in the Commitment phase, they commit to the list of active clients with one broadcast to the other servers, and after verification of all commits, the servers finally output the result of the DC-net. This design allows to handle churn a posteriori, but requires in the best case sequential broadcasts to all the servers. In D, servers are also supposed to be in different jurisdictions: if, as for PriFi, we assume the latency between them is ms, the lower-bound on the added latency for the client is already ms, without including the latency between the clients and the servers, the latency added on the answer (which also needs to go through the servers), and neglecting all processing time. It should be clear that while D has other benefits, its multiple server-to-server messages per round is poorly compatible with low-latency. In PriFi, the servers never communicate among themselves, and send a unique message per round to the relay; furthermore, the clients’ messages do not go through the servers, unlike D (and others mix networks), removing an important lower-bound on the added latency. In our experiment (Appendix, Figure 11), for users, a round-trip ping takes s in D# and ms in PriFi (no pipelining).

8.3 Client Churn

In conventional DC-nets, if any client goes offline, all other clients must recompute and exchange the shared secrets before the communication can continue. Worse, the current communication round becomes undecipherable, forcing the other clients to re-send their payload the next round. Hence, churn in DC-net induces (1) re-transmissions and (2) global downtime where no one can communicate. While re-transmissions are acceptable with PriFi’s small and frequent rounds (e.g., a few KB of payload each ms), too frequent churn could prevent delay-sensitive applications (e.g., VoIP, streaming) to be run on top of PriFi.

Previous systems that use DC-nets (e.g., [9, 57]) argued how churn was tolerable. To our knowledge, our contribution here is the first analysis of the impact of churn in a realistic scenario where nodes are mobile. In other words, we analyze the practicality of deploying a DC-net in a wireless scenario, and show the availability of the network.

Dataset. We used a well-known dataset [43] from CRAWDAD [11] to characterize node mobility. It contains 4 hours of wireless traffic, recorded in a university cafeteria. Those traces contains the Data Link layer (and show the devices’ association and disassociation requests). In the ICRC context, this dataset represents a pessimistic scenario, since node mobility is likely higher in a coffee shop than in a ICRC facility.

The dataset contains occurrences of churn over minutes, in which there are associations ( unique devices) and disassociations ( unique devices).

Dataset Analysis. Each device (dis)connection induces a re-synchronization (i.e., Setup + Schedule) time of milliseconds, where is dominated by the number of servers and clients , and the latency needed to contact them. Figure 10 in the appendix shows typical values for , which is in the order of seconds. Depending on the strategy, this time is either direct downtime, or not if the re-synchronization happens in background. We analyze three strategies:

  1. The naïve approach (N) kills the communication for every churn, and devices experience a downtime of every time.

  2. The abrupt disconnections approach (AD) uses the graceful approach presented above for connections (which can be enforced by the relay), yielding downtime for connections, but assumes a worse-case scenario were all nodes disconnect abruptly (e.g they do not cooperate, or they experience some network failure), yielding a downtime of .

  3. The graceful only approach (GO) assumes no abrupt disconnections. It is an ideal scenario that cannot be guaranteed (e.g., in case of a device running out of battery), but we envision to come close to this scenario, especially since users have incentive to cooperate to maintain a good QoS for everyone.

Strategy # Interrupt. Availability [%] MCD [s]
N 254 98.72792 1.55147
AD 32 99.81778 0.82
GO 0 100 0
Table 1: Estimation of mobility impact on DC-net systems, w.r.t to the ’Cafe’ dataset. In PriFi, the abrupt disconnection strategy (AD) is enforceable by the relay.

We display in Table 1 three metrics for each of these strategies: the first metric is the raw number of communication interruptions, which directly comes from the node mobility in the dataset. The second metric is the network availability percentage, computed as . The last metric is the maximum continuous downtime, the longest network interruption if PriFi is used with the aforementioned dataset. This last metric has direct impact on usability: e.g., a PriFi user doing a VoIP call might experience audio/video freezes for the duration of the downtime.

QoS and Availability. Using PriFi in the coffee shop scenario represented by the dataset [43] would slightly decrease network availability, as churn induces global downtime. However, over h, between and global loss of communication occur, and the network availability ranges between and , depending on the disconnection types. Assuming PriFi clients have incentives to disconnect gracefully (which improves the situation for everyone at a minimal cost), only network failures and other hardware problem yield global downtime. The longest disconnection period is 0.82s in the worst case, which is noticeable by the users using time-sensitive applications (e.g., VoIP), but hopefully is a bearable cost for the level of protection provided.

Figure 9: Size of the anonymity set versus time, when using PriFi in the cafe scenario. This shows among how many users a PriFi client is anonymous.

Anonymity Metrics. In Figure 9, we display the size of the anonymity set versus the time, i.e., among how many participants a PriFi user is anonymous at any point in time. This is an essential anonymity metric that quantifies anonymity.

In particular, the variations are due to user mobility. A high variance means that while connected, a user risks being “less” anonymous if unlucky (and many people disconnect suddenly); should the size of the anonymity set drop to

, anonymity would be lost.

In the analyzed scenario, we start by removing the uninteresting linear component which indicated that over the duration of the experiment, more people joined the coffee shop than left. Then, we display the difference, in percentage, between the actual anonymity set size and the baseline tendency. We see that size of the anonymity set does not vary more than ; The mean number of users is , hence, the worst-case of “anonymity loss” in that scenario is of users, which is tolerable in an anonymity set of users.

Cost of Graceful Churn. We argue that the CPU cost is negligible: the relay does only one additional signature check; each server has to run an additional verifiable shuffle protocol, yet by design servers are well-provisioned servers able to handle several PriFi networks in parallel. Each client has to generate two new pairs of keys, which could be intensive on low-power devices; we envision that clients could generate these keys in advance, keeping them ready in case a churn occurs. All the nodes then have to exchange this information over the network, yet it is a constant and small number of messages, and the total communication is only in , where is the number of servers and is the number of clients.

9 Conclusion

In this paper, we have presented PriFi, an anonymous communication network that gives provable traffic-analysis resistance to its users. PriFi exploits the characteristics of (W)LANs to provide low-latency, traffic-agnostic communication.

PriFi uses DC-nets to provide strong anonymity, in a design that removes costly server-to-server communications and in which clients’ packets remain on their usual network path, avoiding latency bottleneck typically seen in other systems. PriFi also addresses two main shortcomings of other work in this area: first, users are protected against equivocation attack without added latency or costly gossiping; second, disruptions attacks are detected by the relay, with little work from the clients, and no dedicated communication rounds.

Due to its perfect traffic-analysis-resistance property, PriFi has a high-bandwidth usage; yet, this is not a problem in (W)LANs; additionally, the traffic coming from the Internet to the LAN – where the bandwidth bottleneck usually lies – scales linearly with the number of servers, a security parameter of the system.

We have implemented PriFi and evaluated its performance on a realistic setup mimicking the targetted ICRC deployment. Our findings show that various workloads can be handled by PriFi, including VoIP and video conferencing, and that restrictions usually imposed by DC-net in case of churn when users are mobile are not problematic in PriFi. We are currently collaborating with the ICRC to test PriFi on real facilities.

References

  • [1] Barman. Prifi - github, 2017.
  • [2] Barman. Prifi logs - github, 2017.
  • [3] Dan Boneh. The decision diffie-hellman problem. In Proceedings of the Third International Symposium on Algorithmic Number Theory, ANTS-III, pages 48–63, London, UK, UK, 1998. Springer-Verlag.
  • [4] Yu-Chun Chang, Kuan-Ta Chen, Chen-Chi Wu, and Chin-Laung Lei. Inferring speech activity from encrypted skype traffic. In Global Telecommunications Conference, 2008. IEEE GLOBECOM 2008. IEEE, pages 1–5. IEEE, 2008.
  • [5] David Chaum. The dining cryptographers problem: Unconditional sender and recipient untraceability. Journal of cryptology, 1(1):65–75, 1988.
  • [6] David L Chaum. Untraceable electronic mail, return addresses, and digital pseudonyms. Communications of the ACM, 24(2):84–90, 1981.
  • [7] Chen Chen, Daniele E Asoni, David Barrera, George Danezis, and Adrain Perrig. Hornet: high-speed onion routing at the network layer. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, pages 1441–1454. ACM, 2015.
  • [8] Henry Corrigan-Gibbs, Dan Boneh, and David Mazieres. Riposte: An anonymous messaging system handling millions of users. In IEEE Security and Privacy, 2015.
  • [9] Henry Corrigan-Gibbs and Bryan Ford. Dissent: accountable anonymous group messaging. In CCS, pages 340–350, 2010.
  • [10] Henry Corrigan-Gibbs, David Isaac Wolinsky, and Bryan Ford. Proactively accountable anonymous messaging in Verdict. In USENIX Security, 2013.
  • [11] CRAWDAD. A community resource for archiving wireless data at dartmouth, 2016.
  • [12] George Danezis, Roger Dingledine, and Nick Mathewson. Mixminion: Design of a type iii anonymous remailer protocol. In Security and Privacy, 2003. Proceedings. 2003 Symposium on, pages 2–15. IEEE, 2003.
  • [13] DeterLab. Deterlab: Cyber-defense technology experimental research laboratory, 2016.
  • [14] Roger Dingledine, Nick Mathewson, and Paul Syverson. Tor: the second-generation onion router. In USENIX Security, 2004.
  • [15] Michael J Freedman and Robert Morris. Tarzan: A peer-to-peer anonymizing network layer. In CCS, pages 193–206, 2002.
  • [16] Pablo García, Jeroen van de Graaf, Alejandro Hevia, and Alfredo Viola. Beating the Birthday Paradox in Dining Cryptographer Networks, pages 179–198. Springer International Publishing, Cham, 2015.
  • [17] Pablo Garcia, Jeroen Van de Graaf, Germán Montejano, Daniel Riesco, Narayan Debnath, and Silvia Bast. Storage optimization for non interactive dining cryptographers (nidc). In Information Technology-New Generations (ITNG), 2015 12th International Conference on, pages 55–60. IEEE, 2015.
  • [18] Sharad Goel, Mark Robson, Milo Polte, and Emin Sirer. Herbivore: A scalable and efficient protocol for anonymous communication. Technical Report TR2003-1890, Cornell University, 2003.
  • [19] Philippe Golle and Ari Juels. Dining cryptographers revisited. In Eurocrypt, 2004.
  • [20] Tomas Harreveld. Dining cryptographer networks. Computingscience. nl,(June), pages 1–5, 2012.
  • [21] Nicholas Hopper, Eugene Y. Vasserman, and Eric Chan-Tin. How much anonymity does network latency leak? In Proceedings of the 14th ACM Conference on Computer and Communications Security, 2007.
  • [22] Gus Hosein and Carly Nyst. Aiding surveillance: An exploration of how development and humanitarian aid initiatives are enabling surveillance in developing countries, 2013.
  • [23] VoIP Info. Voip qos requirements, 2017.
  • [24] Aaron Johnson, Chris Wacek, Rob Jansen, Micah Sherr, and Paul Syverson. Users get routed: Traffic correlation on Tor by realistic adversaries. In CCS, pages 337–348. ACM, 2013.
  • [25] Anna Krasnova, Moritz Neikes, and Peter Schwabe. Footprint scheduling for dining-cryptographer networks. In International Conference on Financial Cryptography and Data Security, pages 385–402. Springer, 2016.
  • [26] Albert Kwon, Mashael AlSabah, David Lazar, Marc Dacier, and Srinivas Devadas. Circuit fingerprinting attacks: Passive deanonymization of tor hidden services. In 24th USENIX Security Symposium (USENIX Security 15), 2015.
  • [27] Albert Kwon, Henry Corrigan-Gibbs, Srinivas Devadas, and Bryan Ford. Atom: Horizontally scaling strong anonymity. In Proceedings of the Symposium on Operating Systems Principles (SOSP), 2017.
  • [28] Albert Kwon, David Lazar, Srinivas Devadas, and Bryan Ford. Riffle: An efficient communication system with strong anonymity. In PETS, 2016.
  • [29] David Lazar and Nickolai Zeldovich. Alpenhorn: Bootstrapping secure communication without leaking metadata. In 12th USENIX Symposium on Operating Systems Design and Implementation (OSDI 16), 2016.
  • [30] Stevens Le Blond, David Choffnes, William Caldwell, Peter Druschel, and Nicholas Merritt. Herd: A scalable, traffic analysis resistant anonymity network for VoIP systems. In Proceedings of the 2015 ACM Conference on Special Interest Group on Data Communication, pages 639–652. ACM, 2015.
  • [31] Stevens Le Blond, David Choffnes, Wenxuan Zhou, Peter Druschel, Hitesh Ballani, and Paul Francis. Towards efficient traffic-analysis resistant anonymity networks. In SIGCOMM Computer Communication Review, 2013.
  • [32] Stevens Le Blond, Alejandro Cuevas, Juan Ramón Troncoso-Pastoriza, Philipp Jovanovic, Bryan Ford, and Jean-Pierre Hubaux. On enforcing the digital immunity of a large humanitarian organization. In Proceedings of the 39th IEEE Symposium on Security and Privacy, S&P’18, 2018.
  • [33] Stevens Le Blond, Chao Zhang, Arnaud Legout, Keith Ross, and Walid Dabbous. I know where you are and what you are sharing: Exploiting p2p communications to invade users’ privacy. In Proceedings of the 2011 ACM SIGCOMM Conference on Internet Measurement Conference, IMC ’11, 2011.
  • [34] Joseph K. Liu and Duncan S. Wong. Linkable ring signatures: Security models and new schemes. In ICCSA, 2005.
  • [35] Bill Marczak and John Scott-Railton. The million dollar dissident, 2016.
  • [36] Ulf Moeller, Lance Cottrell, P Palfrader, and L Sassaman. Mixmaster protocol version 3, 2000, 2004.
  • [37] S. B. Mokhtar, G. Berthou, A. Diarra, V. Quéma, and A. Shoker. Rac: A freerider-resilient, scalable, anonymous communication protocol. In 2013 IEEE 33rd International Conference on Distributed Computing Systems, 2013.
  • [38] Steven J. Murdoch and George Danezis. Low-cost traffic analysis of tor. In Proceedings of the 2005 IEEE Symposium on Security and Privacy, 2005.
  • [39] C Andrew Neff. Verifiable mixing (shuffling) of ElGamal pairs. VHTi Technical Document, VoteHere, Inc., 2003.
  • [40] L. Nguyen and R. Safavi-naini. Breaking and mending resilient mix-nets. In PETS, pages 66–80, 2003.
  • [41] Andriy Panchenko, Lukas Niessen, Andreas Zinnen, and Thomas Engel. Website fingerprinting in onion routing based anonymization networks. In Proceedings of the 10th annual ACM workshop on Privacy in the electronic society, pages 103–114. ACM, 2011.
  • [42] Birgit Pfitzmann. Breaking an efficient anonymous channel. In Advances in Cryptology-Eurocrypt 1995, 1995.
  • [43] Caleb Phillips and Suresh Singh. CRAWDAD dataset pdx/vwave (v. 2007-09-14). Downloaded from http://crawdad.org/pdx/vwave/20070914/wlan_pcap, September 2007. traceset: wlan_pcap.
  • [44] Ania M. Piotrowska, Jamie Hayes, Tariq Elahi, Sebastian Meiser, and George Danezis. The loopix anonymity system. In 26th USENIX Security Symposium (USENIX Security 17), 2017.
  • [45] Michael K Reiter and Aviel D Rubin. Crowds: Anonymity for web transactions. ACM Transactions on Information and System Security (TISSEC), 1(1):66–92, 1998.
  • [46] Ronald L. Rivest, Adi Shamir, and Yael Tauman. How to leak a secret. In Proceedings of the 7th International Conference on the Theory and Application of Cryptology and Information Security: Advances in Cryptology, ASIACRYPT ’01, pages 552–565, London, UK, UK, 2001. Springer-Verlag.
  • [47] Len Sassaman, Bram Cohen, and Nick Mathewson. The pynchon gate: a secure method of pseudonymous mail retrieval. In WPES, 2005.
  • [48] Satadal Sengupta, Harshit Gupta, Niloy Ganguly, Bivas Mitra, Pradipta De, and Sandip Chakraborty. CRAWDAD dataset iitkgp/apptraffic (v. 2015-11-26). Downloaded from http://crawdad.org/iitkgp/apptraffic/20151126/apptraffictraces, November 2015. traceset: apptraffictraces.
  • [49] Fatemeh Shirazi, Milivoj Simeonovski, Muhammad Rizwan Asghar, Michael Backes, and Claudia Díaz. A survey on routing in anonymous communication protocols. CoRR, abs/1608.05538, 2016.
  • [50] Ewa Syta, Benjamin Peterson, David Isaac Wolinsky, Michael Fischer, and Bryan Ford. Deniable anonymous group authentication. Technical Report YALEU/DCS/TR-1486, Department of Computer Science, Yale University, 2014. Available at http://cpsc.yale.edu/sites/default/files/files/TR1486.pdf.
  • [51] International Telecommunication Union. Itu-t g.114 - amendment 2: New appendix iii – delay variation on unshared access lines, 2009.
  • [52] Jeroen van de Graaf. Anonymous one-time broadcast using non-interactive dining cryptographer nets with applications to voting. In Towards Trustworthy Elections, pages 231–241, 2010.
  • [53] Jelle van den Hooff, David Lazar, Matei Zaharia, and Nickolai Zeldovich. Vuvuzela: Scalable Private Messaging Resistant to Traffic Analysis. In Proceedings of the 25th Symposium on Operating Systems Principles, 2015.
  • [54] Tao Wang, Xiang Cai, Rishab Nithyanand, Rob Johnson, and Ian Goldberg. Effective attacks and provable defenses for website fingerprinting. In USENIX Security Symposium, pages 143–157, 2014.
  • [55] Tao Wang and Ian Goldberg. Improved website fingerprinting on tor. In Proceedings of the 12th ACM Workshop on Workshop on Privacy in the Electronic Society, 2013.
  • [56] David I Wolinsky, Henry Corrigan-Gibbs, Bryan Ford, and Aaron Johnson. Scalable anonymous group communication in the anytrust model. In EuroSec, 2012.
  • [57] David Isaac Wolinsky, Henry Corrigan-Gibbs, Bryan Ford, and Aaron Johnson. Dissent in numbers: Making strong anonymity scale. In OSDI, 2012.

Appendix A Equivocation Protocol

a.1 Equivocation Example

Client and , both honest, are connected to a malicious relay, and they collectively run the PriFi protocol. On the first round, the relay decodes a DNS request for a given domain. As the request was sent through PriFi, it is anonymous, and the relay does not know whether or sent it. However, the relay can, instead of broadcasting the same DNS answer to and , send two different answers to and , containing and , respectively. Later on, the relay decodes a request to and it can guess that made the request (along with the original DNS request), as it is unlikely that has knowledge of .

a.2 Security Analysis

Let be the slot owner, be its plaintext upstream message, be its encrypted upstream message, and be the key used to encrypt into .

We first consider the case that all clients have received the same downstream messages from the relay until the current slot, i.e., . By substituting equations (1)-(3) in Equation (4), and letting , we have Thus, the relay can correctly unblind and decrypt . Note that although the relay learns , due to the hardness of DLP, it cannot learn any information about clients’ ciphertexts, , which could be used to de-anonymize the client.

Now, consider two disjoint non-empty subsets , such that all clients have the downstream history and all clients have the downstream history . From Equation 4,

(5)
(6)

Since , and are disjoint non-empty subsets of , for any choice of in Equation (6), . Therefore, if there is any disagreement among the clients on the downstream history, the relay will not be able to obtain the key to decrypt the owner’s upstream message.

a.3 Abusing the Equivocation Protection

A malicious client or relay might try to falsely accuse the other. For example, to frame the relay, a malicious client might pretend to have received a downstream message different from other clients. Also, a malicious relay might pretend that an honest client is sending wrongly-computed to cause a DoS. These problems can be solved by simply requiring that both clients and servers sign every message they send. When a problem occurs, honest nodes are protected from incorrect blaming, assuming that no party can forge signatures.

A malicious client or server might also send a wrongly computed to cause an anonymous DoS. Note that signing messages cannot prevent such an attack because the relay is unable to validate the correctness of the values. To detect this attack and trace the disruptor, the relay can proceed as follows. First, we assume that the blinding key has a recognizable structure, e.g., a header. When the relay runs the Protocol 4, it will detect the DoS attack by checking the structure of the blinding key obtained. If the blinding key’s structure is incorrect, the relay determines that an attack is in place and follows a procedure similar to the disruption protection protocol (Section 5). That is, the relay stops the communications and sends a signed request to all clients and servers asking them to reveal the hash of the pads used to compute their current values. If there is a mismatch between a and the values sent by a client or server, then this client or server is considered the disruptor. Otherwise, the relay compares the values revealed by the clients with those revealed by the servers. There must be a difference, without loss of generality, among one of the values revealed by one client and one server. After identifying a mismatch between a client and a server, the relay requests that they reveal their shared secret , along with a zero-knowledge proof showing was computed correctly. To generate the pads for the disrupted round, the relay seeds the PRG with these secrets. At this point, the relay will be able to determine which one, the client or the server, disrupted the round and exclude it from the system.

Appendix B Additional Evaluation Results

Figure 10: Experimental evaluation of the network downtime (i.e. where no communication can happen) in case of abrupt disconnection, averaged times, with percentiles. The time is lower-bounded by the latency to the servers.
Figure 11: Experimental comparison of PriFi and Dissent in Numbers. Despite our efforts, Dissent in Numbers did not reach the Communicating state after clients, remaining in a configuration phase.