Vuvuzela: Scalable Private Messaging Resistant to Traffic Analysis Jelle van den Hooff, David Lazar, Matei Zaharia, Nickolai Zeldovich MIT CSAIL Symposium on Operating Systems Principles (SOSP), 2015 1 / 12
Motivation Encryption systems hide only content of messages Protection of metadata is critical for privacy Strong, provable privacy guarantees XOR scalability “If you have enough metadata, you don’t really need content.” Stewart Baker “We kill people based on metadata.” Michael Hayden 2 / 12
Vuvuzela — Goals Private point-to-point messaging Scalable (millions of users, tens of thousands of messages per second) Limited amount of information about communication patterns over time No availability guarantees 3 / 12
Vuvuzela — Goals Private point-to-point messaging Scalable (millions of users, tens of thousands of messages per second) Limited amount of information about communication patterns over time No availability guarantees Vuvuzela gives Alice differ- Alice Bob Charlie Alice Bob Charlie Alice Bob Charlie ential privacy: any event ob- served by the adversary has roughly equal probability in all worlds. ? ? ? Vuvuzela Vuvuzela Vuvuzela 3 / 12
Vuvuzela — Threat Model Strong, active attacker that. . . controls all but one (any) of the Vuvuzela servers controls an arbitrary number of clients monitors/blocks/delays/injects traffic on any network link CC BY 3.0 US “Electronic Frontier Foundation” https://www.eff.org/pages/eff-nsa-graphics 4 / 12
Vuvuzela — Assumptions/Prerequisites Standard cryptography: encryption, key exchange, signatures, hashes Established public keys for Vuvuzela servers and users (PKI) Bug-free implementation 5 / 12
Overview Single chain of Vuvuzela servers Users connect to first server Last server hosts dead drops Mix messages and randomly add fakes Fixed-rate, fixed-size encrypted messages → fixed number of conversations/client Two protocols: dialing + conversion Chain of Vuvuzela servers (only one must be trusted) Alice Bob Adversary that observes Charlie all network tra ffi c 6 / 12
Dialing Protocol Dialing round every 10 minutes m large invitation dead drops Invitation for user with public key pk stored in H ( pk ) mod m Special no-op dead drop (3) Users retrieve their invitations directly 1 2 Alice 3 4 Bob 5 6 Charlie (1) Users send (2) Honest server mixes invitations and adds cover tra ffi c 7 / 12
Conversion Protocol (Strawman) Synchronous rounds coordinated by first server Ephemeral conversation dead drops with 128-bit ID (1) Alice and (2) Alice sends Bob agree on “Hi, Bob!” Adversary can a dead drop Alice see Alice and to use Bob talking (3) Dead drop Bob holds message (4) Bob reads message Charlie (2b) Charlie sends write message, but his read partner isn’t here 8 / 12 141
Conversion Protocol Dead drop selected based on shared secret derived from public keys of communication partners and round number Alice Bob Charlie (1) Users access (2) Honest server (3) Adversary can’t tell dead drops unlinks users from who is talking to who dead drops and by looking at dead adds cover tra ffi c drop access patterns 9 / 12 140
Evaluation Prototype Implemented in Go with ~ 2700 SLOC No CDN- or Torrent-based distribution for dialing protocol 10 / 12
Evaluation Prototype Implemented in Go with ~ 2700 SLOC No CDN- or Torrent-based distribution for dialing protocol Setup Amazon EC2 virtual servers: 36 Xeon E5-2666 v3, 60 GiB RAM, 10 Gbps network 3 Vuvuzela server 5 servers to simulate clients Dedicated (untrusted) entry server Deterministic amount of nose, i.e. number of fake messages 80/256 bytes per dialing/conversation message 5 % of users dial another user each dialing round 100 clients fetch their dialing dead drop + extrapolation of required bandwidth 10 / 12
Results 60 s 60 s µ=300,000 µ=13,000 conversation messages End-to-end latency for End-to-end latency for µ=200,000 50 s 50 s dialing invitations µ=100,000 40 s 40 s 30 s 30 s 20 s 20 s 10 s 10 s 0 s 0 s 10 500,000 1M 1.5M 2M 10 500,000 1M 1.5M 2M Number of online users Number of online users 1.2M fake message 12 kB/s per user With 1M users and µ = 300 k: 37 s end-to-end 12 GB/sec in aggregate latency, 68k messages/s, 166 MB/s per server, 10s of seconds per round Limiting factor: 340k Curve25519 DH operations per second and server 11 / 12 148 148
Conclusion Private messaging system scalable to millions of users Protects against traffic analysis of powerful attacker Minimizes observable variables and hides them with noise Quantifiable security properties High bandwidth demands (especially on servers) 12 / 12
Recommend
More recommend
