Reliable MIX Cascade Networks Through Reputation

1. Reliable MIX Cascade Networks Through Reputation By Roger Dingledine and Paul Syverson Presented by Naveen Santhapuri Roopa Raju

2. Outline • Anonymity • MIX Cascades and MIX Networks • Threats and Attacks • Approaches for Reliability • Reputation Systems • Self building Cascades with Reputation • Defenses against attacks • Some Anonymity Architectures • Conclusion

3. Anonymity • The quality or state of being unknown • Required in privacy critical systems like voting • Pseudonymity! What is it? - anonymity in a certain sense but not anonymous

4. Downsides and Uses • Hit-and-run actions (mostly on the net) • Haven for illegal practices like espionage, terrorist activities • So why do we want anonymity? - Privacy in general - Voting - Maintenance of free speech - Medical surveys and Testing

5. Anonymity through remailers • Basic idea: Messages are encrypted, envelopes within envelopes making tracing based on external appearance impossible • Untraceable mail - Situation for ordinary mail - Imagine postal service demanding personalized stamps, verifiable return addresses, etc

6. Implementing a Remailer – Chaum’s Digital MIX • Based on public key cryptography MIX

7. MIX Mechanism • A sends a message M to B via MIX • MIX: KUMIX [ R1, KUB(R0,M), B ]  KUB(R0,M) • Purpose is to hide correspondences • An important function of MIX is to ensure no item is processed more than once

8. MIX Cascades M3 MIX MIX M4 M1 M2

9. MIX Cascades • Series of Mixes • A sends a message M to B via a MIX cascade with n MIXs • KUn [ Rn, KUn-1[…. KU1[R1, KUB(R0,M)]]….] • Untraceable Return Addresses – possibility for certified mail

10. MIX Network • Impractical to pass every message through every MIX in a large system • A network of freely usable Mixes • More flexible than a MIX cascade - user can choose the path - scope for more anonymity (!?)

11. Types of Adversaries • Anonymity breaking adversary - Identify the sender or receiver • Reliability breaking adversary - Deny service to users • An adversary can - Passively read all traffic - Compromise some fraction of the Mixes (Insert, modify, delay or drop messages)

12. Problems with Single MIX • Message size - must be uniform • Replay - no message should be processed twice • Manipulation of messages - need for integrity • Blocking of messages - limitation of anonymity group

13. Anonymity Measure: MIX-Net and MIX cascade • Anonymity stays the same in a cascade when all messages are forwarded correctly • In a MIX-Net, anonymity group of senders is the union of anonymity of all the MIXs (only if all MIXs are trustworthy) • If participants join and leave, anonymity is only among those senders who were part of the group for the whole time

14. Are MIX-Nets Better than Cascades ? • Attacker has to control many MIXes to succeed • MIX network can theoretically grow to infinite size so, anonymity group will also raise to infinite size • No structure, so MIX-net is scalable, flexible • But wait…

15. Intersection attacks • If only one MIX of the route is good, anonymity is distinctly lower compared to a synchronous cascade

16. Intersection attacks • Possible solution: use dummy messages between MIXs

17. Approaches to improve Reliability • Using MIX protocols with provable robustness guarantees (Ex: FLASH MIX) • More reliable software • Incentives for MIXs to stay reliable • Reputation system

18. Reputations Systems • Reputation Systems improve reliability of MIX-nets by allowing users to avoid unreliable MIXs • Solving the problem of pinpointing failures by using digitally signed receipts • Using witnesses

19. MIX-net with witnessed failures

20. Scoring System • Raters make observations • Scores tally observations and make them available • Scores include both a count of –ve ratings and also a minimum number of +ve ratings

21. Ratings and Attacks • Ratingscan be made reliable by weighting them with the credibility of raters • Witnesses send test messages to gauge credibility • Adversary could gain more reputation and get more traffic routed to it

22. Self Building Cascades with Reputation for Reliability

23. Basic ideas in the paper • Randomly self build the cascades through a reputation system • Eliminate the need for globally trusted witnesses • To avoid an adversary gain a high reputation

24. Randomly self building cascades… Cascades rebuilt every period ‘T’ • At T-a-b, each participant sends sealed commitment to CS& CS publishes the set of commitments Commitment from N: sign(N,[N,IP,port,bandwidthpledge,tsbc(randN)]). • At T-b ,participants reveal to CS • At T ,CS publishes set of reveals. Reveal from N: sign(N,[N,IP,port,bandwidthpledge,randN])

25. Communal Randomness • Communally determined • Unpredictable • Calculated from collecting random values from participating mixes • Kept secret until everyone has committed tsbc(randN)=<enc(K,randN),w(K)>

26. Reputation System • The system decrements the reputation of all the nodes in a failed cascade and increments the reputation of all nodes in a successful cascade. • Creeping death: behavior of bad nodes can affect reputation of its cascade members. E.g. Consider a cascade with few bad nodes than good nodes…

27. Reputation System (cont’) • Adversary with many nodes can still succeed - Limit the number of nodes adversary can get certified using web of trust like Advagato • Advagato’s trust metric: - Number of bad nodes certified is based on number of confused nodes (good nodes that might certify bad nodes)

28. Building cascades • Order the nodes by their reputation • Choose the nodes for the first cascade randomly from a pool of nodes at the top of reputation spectrum • Next-highest reputation nodes are added to the pool to maintain it’s size • Another cascade is formed at random

29. Deciding Pool Size • p - fraction of nodes that are bad, s - scare factor (acceptable probability of adversary controlled path), r - range (size of the pool from which nodes are chosen for a single cascade), l - length of a single cascade, c - chain length (number of cascades chained together

30. Cascade protocol • Opportunities to misbehave in cascades - Entry point: incoming messages might not be accepted - Inside the cascades: Messages might be replaced with dummy messages - Exit point: Messages might not be delivered

31. At entry point • Sender can send message to any node. All nodes deliver to the head and give sender a receipt • Head publishes batch snapshot • Sender checks in the batch for his message • If not found, he broadcasts the message with the receipt to other nodes in the cascade • An honest cascade member then fails the cascade

32. Inside the cascade • A dishonest head can publish a correct batch but replace its portion with dummy messages • Sender might become suspicious and send a test message • Sender also reveals the decryption to everyone • An honest node will check and fail the cascade

33. At exit point • Message recipients give tail (T) a receipt (or) If tail does not get a receipt, it can broadcast the message to the other members of the cascade • Sender might become suspicious and contact a node (N) and complain about T, along with the decryption • N already knows from broadcast (or) If receipt not found at T, N fails the cascade

34. Delivery receipts • Message recipients a give the tail a receipt when he delivers the message. • Can be used to prove that he delivered the message. • Detect misbehavior (as long as one of the nodes in the cascade is honest)

35. Capacity attacking adversary • Nodes can refuse incoming messages by falsely claiming to be full • Solution: insert indistinguishable test messages into its own batches, and verifying that each of the other nodes are successfully decrypting, providing minimum level of anonymity

36. Resource management and Reputation Servers • Cascades need to publish available capacity information, including expected wait or available quality of service for messages • Users can compare reputation and available QoS from each cascade to balance the load across the cascade • Group of redundant reputation servers (RS) can be used

37. Detecting & Defending Attacks • Attacks on Anonymity - Having enough nodes to own the cascade - Gaining high reputation to read more traffic - Replay attacks, message delaying etc - Intersection attack - Influence cascade configuration externally - Compromise the Cascade configuration server - Knock down uncompromised cascades to get more traffic

38. Detecting & Defending Attacks • Attacks on Capacity and Reliability - Flood nodes with messages - Knock down many cascades - Block commitments to configuration server - Flood CS with commits - Refuse commitments at the CS - Selectively process only test messages

39. Detecting & Defending Attacks • Attacks on Reputations - Beat the web of trust - Internal selective DoS-creeping death - External selective DoS-knock down high reputation cascades

40. Some Existing Architectures • Remailer - Don’t work in a deterministic way which makes attacks complicated though attacks are theoretically possible • Onion Routing (Freedom ) - Prevents attacks from external observers and isolated attacking MIXs • Crowds – random routes - Protection only from isolated observations

41. Future directions • Reducing bandwidth overhead • Improved cascade configuration algorithms to provide stronger anonymity and reliability • Research on creeping death attacks • Adopting this design to free-route Mix networks. • Complete Solution to Intersection Attacks

42. Questions?