Karaoke. Distributed Private Messaging Immune to Passive Traffic Analysis. David Lazar, Yossi Gilad, Nickolai Zeldovich

Transcription

1 Karaoke Distributed Private Messaging Immune to Passive Traffic Analysis David Lazar, Yossi Gilad, Nickolai Zeldovich 1

2 Motivation: Report a crime without getting fired You re Fired if you talk to the journalist! Bob Journalist Govt. Boss (Adversary) Govt. Employees!2

3 Goal: Metadata-Private Text Messaging Text Messaging App Bob!3

4 Threat Model: Global Adversary Watches the network Runs some of the servers Can we prevent him from learning who Bob is chatting with? Bob!4

5 Prior Approaches Vuvuzela [SOSP 15] Stadium [SOSP 17] Pung [OSDI 16] Dissent [OSDI 14] Privacy No Privacy Guarantee Differential Privacy Cryptographic Privacy!5

6 Prior Approaches Vuvuzela [SOSP 15] Stadium [SOSP 17] Pung [OSDI 16] Dissent [OSDI 14] Privacy No Privacy Guarantee Differential Privacy Cryptographic Privacy Scalability!6

7 Scalability is critical for security Bob Whistleblower Journalist!7

8 App must scale to everyone, so it isn t suspicious when Bob joins Bob Whistleblower Journalist!8

9 Contributions Karaoke: a distributed metadata-private messaging system that scales to more users Cryptographic privacy against passive attackers. Differential privacy against active attackers. 8s end-to-end latency with 4M users. 5x to 11x faster than prior work.!9

10 Insight: treat passive and active attackers separately Privacy No Privacy Differential Privacy Cryptographic Privacy active attacker Karaoke passive attacker Scalability!10

11 Global Passive Adversary Watches the network Runs some of the servers!11

12 Observations by Adversary Inputs Server State + Network Links Outputs!12

13 Observations by Adversary Inputs!13

14 Hiding inputs: constant cover traffic in rounds Round 1 Round 2!14

15 Hiding outputs Outputs!15

16 Hiding outputs with dead drops [Vuvuzela] Dead drop: designated location to exchange messages. Named by pseudorandom ID, so reveals nothing about the users. When two users access the same dead drop, their messages are exchanged. Idle users result in dead drop with one access.!16 Dead drops

17 Dead drops alone are insufficient Chatting Not Chatting Alice Bob Obvious from outputs if Alice and Bob are chatting.!17

18 Vuvuzela generates dummy accesses (noise) Chatting Not Chatting Differential privacy: no single round reveals much, but many rounds of observation might reveal a pattern.!18

19 Karaoke dead drops are always doubles Chatting Not Chatting!19

20 Message doubling provides cryptographic privacy Chatting Not Chatting Cryptographic privacy: adversary can t distinguish whether Alice and Bob are chatting!20

21 Observations by Adversary Inputs Server State + Network links Outputs!21

22 Mixnet Review Dead drops Guarantee: if one server is honest, adversary can not tell which users accessed which dead drops!22

23 Distributed Mixnet: each server processes subset of messages !23

24 Users pick random paths through the network Hop 1 Hop 2 Hop 3 Hop 4!24

25 Servers decrypt and shuffle incoming messages at each hop Hop 1 Hop 2 Hop 3 Hop 4!25

26 Last hop does the dead drop exchanges Dead drops Hop 1 Hop 2 Hop 3 Hop 4!26

27 Challenge: network links between hops show Alice is talking to Bob! Hop 1 Hop 2 Hop 3 Hop 4!27

28 Karaoke s message doubling gives us some hope! Hop 1 Hop 2 Hop 3 Hop 4!28

29 Possible cases for the last hop Chatting Not Chatting Goal: make these cases indistinguishable so the rest of the links don t matter.!29

30 Tangled Messages = OR!30

31 Tangling one of Alice s and one of Bob s messages achieves our goal Tangled Messages = OR Last hop!31

32 An honest server tangles messages Last hop!32

33 Problem: Alice and Bob s messages might not intersect at an honest server Last hop!33

34 Problem: Alice and Bob s messages might not intersect at an honest server Assume the paths of Alice s and Bob s other messages are completely compromised.!34

35 Karaoke servers generate dummy messages that can be used for tangling 1 3 noise 2 4 Bob!35

36 Bob s message is now tangled with noise 1 3 noise 2 4 Bob!36

37 Similarly, Alice s message can tangle with noise Alice 1 3 noise 2 4!37

38 Is it possible that the noise messages swapped places? !38

39 As a result, Alice s and Bob s messages could also have switched places !39

40 Tangling with high probability The shape we just saw is a bit complicated, but it enables Alice and Bob to get tangled with high probability Assuming 80% of the servers are honest 14 hops results in tangling with high probability Servers need to add a small amount of noise messages per outgoing link!40

41 Karaoke Summary Inputs Server State + Network links Dead drops!41

42 Defending against a global active adversary Karaoke provides differential privacy against a global active adversary Karaoke adds additional noise messages to protect against message drops Due to message doubling, active attacks (message drops) are rare and detectable, so Karaoke needs far less noise compared to prior work. We use bloom filters to ensure malicious servers don t discard the noise. (See paper)!42

43 Implementation 4000 lines of Go code Major CPU cost is onion decryption Configured to resist 200 active attacks per user (see paper)!43

44 Evaluation Does Karaoke support a large number of users with good end-to-end latency? How does Karaoke s performance compare to prior work? Does it scale? (i.e., does Karaoke support more users by adding more servers?)!44

45 Experimental Setup 50 to 200 Amazon EC2 instances c4.8xlarge (36 cores) instances for comparison to Vuvuzela and Stadium c5.8xlarge instances for all other experiments 10 Gbps links 100 ms of simulated network latency between instances!45

46 Karaoke achieves low latency for many users 160 s 140 s 120 s 136s Karaoke Vuvuzela Stadium Latency for user messages 100 s 80 s 60 s 40 s 20 s 0 s 68s 55s 37s 10s 6s 8s 10s 39s 35s 27s 22s 16s 2M 4M 6M 8M 10M 12M 14M 16M Number of users!46

47 Karaoke is CPU bound 160 s 140 s 120 s 136s Karaoke (c5) Karaoke (c4) Vuvuzela Stadium Latency for user messages 100 s 80 s 60 s 40 s 20 s 0 s 68s 55s 37s 16s 10s 6s 8s 10s 6s 6s 7s 8s 39s 35s 27s 22s 27s 28s 18s 16s 2M 4M 6M 8M 10M 12M 14M 16M Number of users!47

48 Karaoke supports more users by adding servers Latency for user messages 12 s 10 s 8 s 6 s 4 s 2 s 0 s 25K users/server Number of servers!48

49 Conclusion Karaoke: distributed metadata-private messaging system that scales to more people Cryptographic privacy against passive attackers Technique: message doubling + message tangling 8 seconds end-to-end latency for 4 million users 5x-11x faster than Vuvuzela/Stadium!49

50