Lec 20: Case study: Tor Past few lectures: security in the content of storage systems Today: case study of security in a communication systems Goal: anonymous communication e.g., hide IP address from where user is browsing why? protect user from Web server protect user from oppressive government, employer, etc. etc. intellectually challenging problem General method: mixnet large network of mixes sender: chose a random subset of all mixes create message put it in envelop 0 and put recipient's address on it put envelop 0 in envelop 1 with the address for mix 1 put envelop 1 in envelop 2 with the address of mix 2 etc. send message: send message to mix n mix n opens envelop n and forwards envelop n-1 to mix n-1 etc. potential additional measures: ensure that mix cannot open and modify messages mix send and i setup keys to encrypt and authenticate envelop i (and its content) thwart traffic analysis by global observer send all data in fixed-size messages (pad the message) delay and reorder messages generate cover traffic recipient or adversary: knows that the message came from mix n-1, but (hopefully) cannot find path through mixnet and identify the IP address of the sender. attacks what if adversary compromises some mixes? what if adversary can content of some messages? what if adversary can modify message? what if adversary can observe some traffic in network? what if adversary can observe all incoming and outgoing traffic? etc. Tor: the Second-Generation Onion Router Dingledine, Mathewson, and Syverson goals: low-latency anonymous TCP connections deployability usability flexibility simple threat model; no global adversary! no end-to-end confirmation attacks no intersection attacks traffic analysis attacks by observing some fraction of network traffic make it difficult for attacker to learn nodes to attack e.g., for confirmation attack modify, delete, delay traffic operate a few mixes compromise a few mixes basic plan: network of onion routers (ORs) connects in a full mesh with TLS links ORs know the public keys from all ORs. Can OR trust public key? all traffic is sent in fixed-size cells (512 bytes) user configure browser to use onion proxys as Web proxy. OP speaks SOCKS OP sets up and breaks down a circuit through a path of ORs OP knows public keys of all ORs OP incrementally builds up circuit sets up shared keys with each OR Frequently rebuild circuit. why? user enter URL OP receives URL from browser danger: browser resolved DNS name! OP sets up stream to an exit OR on a circuit stream control cells are relayed like data cells OP relays cells along circuit to chosen exit OR OP encrypts messages recursively. why? messages have a digest. why? only exit OR checks digest. why? exit OR connects to Web server and tell OP when successful OP accepts data from browser and relays it through the stream Web server knows IP address of exit OR send response to exit OR, which relays relays through the stream each OR encrypts multiple TCP connection over a single circuit several users may share OR features: forward secrecy. why? no mixing, padding, or traffic shaping. why? leaky-pipe topology. why? congestion control. why? trusted directory servers. why? variable exit policies. why? rendezpoints and hidden services. why? http://en.wikipedia.org/wiki/Tor_(anonymity_network) http://www.cl.cam.ac.uk/users/sjm217/papers/oakland05torta.pdf