Slicing the Onion: Anonymous Routing Without PKI

Slicing the Onion: Anonymous Routing Without PKI

Slicing the Onion: Anonymous Routing Without PKI Sachin Katti Dina Katabi Katarzyna Puchala [email protected] [email protected] [email protected] Abstract– Recent years have witnessed many proposals for to the nodes. But such an approach is problematic for many anonymous routing in overlay peer-to-peer networks. To provide reasons. First, in a large peer-to-peer network, the trust model both sender and receiver anonymity, the proposed protocols require may differ from one node to another (e.g., nodes in Cuba the overlay nodes to have public-private key pairs, with the public may not trust the same PKI as nodes in the US). Second, it keys known to everyone. In practice, however, key distribution and opens up the system to attacks on the key distribution proce- management are well-known difficult problems that have crippled dure and compulsion attacks that force the key originator to any widespread deployment of anonymous routing. In this paper, disclose the keys under the threat of force or if required by a we propose a novel protocol that uses a combination of information court order [12, 13]. Indeed, some countries have provisions slicing and source routing to provide anonymous communication that allow them to legally request the decryption of material similar to Onion Routing but without a public key infrastructure. or the handing over of cryptographic keys [6, 9]. Addition- ally, PKI makes anonymous multicast difficult as all recip- 1INTRODUCTION ients of a multicast message have to share the same public private key pair. Finally, with time, an increasing fraction Anonymous routing plays a central role in private com- of the keys can get stolen off compromised machines. This munication. Its applications range from file sharing to mili- necessitates the existence of key management and update tary communication, and include anonymous email, private protocols, complicating the problem further. web browsing and online voting. Traditionally, anonymous This paper shows how to perform anonymous Onion Rout- routing has required the help of a trusted third party, which ing without PKI. Onion routing [11] is at the heart of most either acts as a centralized proxy [1, 3], or provides the prior work on peer-to-peer anonymizing networks [8, 10, 15, sender with the public keys of selected willing relays [2, 19]. It uses a form of source routing, in which the IP address 8]. However, the recent success of peer-to-peer systems has of each node along the path is encrypted with the public evoked interest in using them as anonymizing networks. In- key of its previous hop. This creates layers of encryption– deed, the large number of nodes (a few million [14]) and layers of an onion. To send a message, each node decrypts the heterogeneity of their location, communication patterns, one layer, discovers its next hop, and forwards the mes- political background and local jurisdiction make these net- sage. Thus, each relay node knows only its previous and works ideal environments for hiding anonymous traffic. Many next hops; it cannot tell the sender, the receiver, the path, systems have been designed to exploit peer-to-peer over- or the content of the message. Our scheme provides similar lays in anonymous communication, including Tarzan [10], anonymity but without PKI. AP3 [15], MorphMix [17] and Cashmere [19]. But to pro- Our approach is based on the simple but powerful idea vide sender and receiver anonymity, these systems require of Information Slicing. To provide anonymous communi- the overlay nodes to have public-private keys obtained through cation, each node along the path, the destination included, a trusted authority; i.e., they require a public key infrastruc- needs a particular piece of information, which should be hid- ture (PKI).1 den from other nodes in the network. For example, the des- But why is PKI problematic for peer-to-peer anonymiz- tination needs to learn the content of the message without ing networks? Key distribution and management are well- revealing that content to other nodes, while each intermedi- known difficult problems [4]. In particular, prior work as- ate relay needs to learn its next hop without other nodes in sumes the sender knows a priori the public keys of all re- the network knowing that information. We divide the infor- lay nodes [10, 15, 19]. The underlying assumption is that mation needed by a particular node into many small random a trusted third party generates all keys and distributes them pieces. These information pieces are then delivered along 1A few systems (e.g., Crowds [16]) do no require PKI, but they expose the disjoint paths that meet only at the intended node.Thus, only receiver and message content. the intended node has enough bits to decode the information content. We call this approach information slicing because it splits the information traditionally contained in an onion peel (i.e., the ID of the next hop) into multiple pieces/slices. Anonymity via information slicing is not as straightfor- ward as it sounds. To send a particular node the identity of its next hop along different anonymous paths, one needs to anonymously tell each node along these paths about its own Figure 1—Node S sends a confidential message m to X by first multi- ∗ next hop. Without careful design, this may need an exponen- plying the message with a random matrix I = Am , then splitting the resulting information content into multiple pieces, each follows a dis- tial number of paths. Our keyless onion routing algorithm joint path to X. Only X receives enough information bits to decode the provides efficient information slicing using a small constant original message as m = A−1I∗. number of paths. The rest of the paper describes the details of our informa- tion slicing protocol, and shows how to construct forward- leading to the receiver. This assumption can be ignored if ing graphs that deliver anonymous messages using a small the sender knows the receiver’s key, which guarantees mes- sage confidentiality even if the attacker can collect all infor- number of paths. It also presents our preliminary implemen- 2 tation results showing that the latency of setting up anony- mation slices sent to the receiver. mous routes in our scheme is low enough to be practical. 3ANONYMOUS COMMUNICATION WITH- OUT PKI 2GOALS &MODEL Our approach to anonymity without PKI stems from a The objective of this work is to enable large and fully simple observation: anonymity can be built out of confi- distributed peer-to-peer anonymizing networks. We focus dentiality. In particular, for anonymous communication, the on pragmatic anonymity for non-military applications, such source needs to send every relay node along the path its rout- as file sharing, private email and the communication of med- ing information (i.e., its next hop) in a confidential message, ical records. These applications strive for privacy but can accessible only to the intended relay. One can send confiden- deal with low probability of information leakage. tial messages without keys using a simple building block: We assume an adversary who can observe some frac- information slicing. tion of network traffic, operate relay nodes of his own, and Consider the scenario in Fig. 1, where sender, S, wants can compromise some fraction of the relays. We do not pro- to send message m to node X. The sender divides the mes- tect against a global attacker who can snoop on all links. sage into d blocks mi, ∀i ∈{1, ..., d}, such that the orig- Though such an adversary is usually assumed when analyz- inal message can be recovered only when a node has ac- ing theoretical anonymity designs, all practical low-latency cess to all d blocks. Sending a message block mi in the clear anonymizing systems, ours included, do not protect against may expose partial information to intermediate nodes. Thus, such an adversary [8, 10, 15, 17, 19]. Also, similar to prior the sender multiplies the message vector m =(m1, ..., md) work [8, 10, 15, 19], we generate enough cover traffic to with a random but invertible matrix A and generates d slices prevent simple traffic analysis attacks. which constitute a random version of the message: We also assume the sender can send from multiple IP addresses, and a secure channel like ssh is available be- I∗ = Am . tween them. Many people have Internet access both at home and at work/school, and thus, can send from different IP ad- Then, the sender picks d disjoint paths to node X. It sends dresses. Alternatively, the sender may have both DSL and ∗ on path i both the slice Ii and Ai, where Ai is row i of A. cable connectivity. Or, he may belong to a multi-homed or- ∗ An intermediate node sees only some random values I i and ganization. For example, each of the authors has Internet Ai, and thus cannot tell the content of the message. Once the access at home, as well as at school and on Planetlab ma- receiver receives all slices, it decodes the original message chines. We believe that a large number of Internet users can as: send from multiple accounts with different IP addresses. An m = A−1I∗. attacker may try to correlate IP addresses belonging to the same sender. However, in all of the examples above the IP This slicing mechanism could be considered as a variation addresses used belong to different domains. Additionally, on the concept of secret sharing [18] customized for the our most broadband providers and companies utilize NAT, pre- problem (see §6). venting the association of an IP address with a particular 2Note that knowing the receiver’s key is a much weaker constraint that user.

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    6 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us