What’s the scuttlebutt on Secure Gossip ?

1. What’s the scuttlebutt on Secure Gossip? Robbert van Renesse

2. Secure Gossip orGossip for Security? • Secure gossip: making sure probabilistic guarantees hold in the face of malicious behavior • Gossip for security: exploit robustness of gossip for spreading important information (certificate revocation lists, security patches, …) movement from former to latter?

3. Scale  Security • Gossip often said to scale well • But in large settings more chance of bad behavior of participants • Spreading false rumors • Introducing too many rumors • Not forwarding good rumors • …

4. What have people worked on? • Integrity • Preventing spreading of false gossip without the use of digital signatures • Availability • Making sure everybody receives all gossip • Fairness • Everybody does its share of forwarding

5. 8 years - 8 papers • 1999 Malkhi, Mansour, Reiter • On diffusing updates in a Byzantine environment • 2001 Malkhi, Reiter, Sella • Optimal unconditional information diffusion • 2003 Minsky, Schneider • Tolerating malicious gossip • 2003 Malkhi, Pavlov, Sella • Gossip with malicious parties • 2004 Badishi, Keidar, Sasson • Exposing and eliminating vulnerabilites to DoS attacks in secure gossip-based multicast • 2006 Johansen, Allavena, Van Renesse • Fireflies: Scalable Support for Intrusion-Tolerant Network Overlays • 2006 Haridasan, Van Renesse • Defense Against Intrusion in a Live Streaming Multicast System • 2006 Li, Clement, Wong, Napper, Roy, Alvisi, Dahlin • BAR Gossip

6. Malkhi et al. take 1(Srikanth/Toueg) • Integrity without digital signatures • Assume initially at least t +1 nodes have valid gossip • A node does not forward gossip until it thinks it is valid • A gossip becomes valid when it has been received from at least t + 1 nodes • Bad nodes cannot generate valid gossip • Slow…

7. Malkhi et al. take 2 • Initially t + 1 nodes have valid gossip • Nodes maintain set of source paths for each gossip. Initially 1 empty path. • Gossip messages contain all paths. • On receipt of gossip from p, a node adds p to all paths before adding to set of paths. • On receipt of t + 1 disjoint paths, gossip can be delivered. • Fast, but very large messages

8. Malkhi et al. take 3Minsky & Schneider • Practical versions that only maintain a subset of paths • Useful up to a dozen bad nodes or so But there’s always public key signatures…

9. Keidar et al. • Prevent application-level DoS attacks • Send digests on publicly known ports, actual data on randomly generated ports • Randomly pick messages to exchange from digests to prevent being overwhelmed by bogus messages

10. Van Renesse, Allavena, JohansenFOO gossip (Fireflies Ordered Rings) • Large fraction of bad nodes • Generate a pseudo-random mesh that connects all correct nodes with high probability • Gossip on mesh, using public key crypto for integrity • Use persistent connections between nodes, reducing need for full merges • Throttle state transfer for joins • Moderate scalability, but can be fixed I think

11. Haridasan, Van RenesseSecureStream • Video streaming with many bad hosts • Carefully flood video frames on pseudo-random mesh using a notify/pull strategy • Prefer nodes that sent data to you over nodes that don’t • Deals pretty well with freeloaders • Approach under development deals well with heterogeneity as well

12. Li, Alvisi et al.BAR gossip • Elegant game-theoretic approach to dealing with rational and Byzantine nodes (See RFC3092 for FOOBAR origins)

13. Fireflies Gossip • Sign data for integrity • Even if large fraction of participants do not forward gossip, still O(log N) completion time • But Byzantine members can launch a “reverse” Denial-of-Service attack • By claiming to know nothing • Causes correct members to xmit all state • Root cause: lack of connections

14. Solution: partial membership gossip with persistent connections Erdös & Rényi: if probability of link is high enough, graph will be connected with high probability Chung & Lu: such a graph will have logarithmic diameter

15. Pseudo-Random Mesh k rings: • Each member obtains public key certificate from CA • Member’s id is verified by CA • Each member calculates k positions using a secure hash function • H ( id, ring )  position • Connect to successor and predecessor k chosen such that correct members form a connected graph with high probability

16. Working out the math… • k : out degree • N : correct + Byzantine members • n : correct members • : probability of graph being connected But what about crashed members???

17. Fireflies Membership • Members are correct, crashed, or Byzantine • (Cannot necessarily tell Byzantine from correct or crashed members) • Correct members have a view • p, q both correct  q in p’s view • p correct, q crashed  q not in p’s view With probabilistic real-time bounds…

18. Protocol Structure Accuse and rebut Deliver within  Membership Gossip Pinging Set Reconciliation Monitor and suspect Exchange diffs EACH COMPONENT IS PROBABILISTIC

19. Here’s the problem… • If correct members can make mistakes and falsely accuse correct members, how can we prevent Byzantine members from falsely accusing correct members??? (Answer: we don’t have to)

20. Membership 2t + 1 rings: Each member can only accuse its 2t + 1 successors t chosen such that each member has no more than t Byzantine predecessors whp

21. 53 53 Node identifier Node identifier 1 1 2 2 3 3 4 4 5 5 Data Structures Serial number Note Accusation t + 1 rings enabled t rings disabled Ring: 3 Accuser: identifier • Both signed by creator • Both gossiped  everybody’s got the same set

22. Membership Protocol • On each ring, monitor the first successor that hasn’t been accused • Gossip accusation if successor suspect • If you’re accused, gossip a new note (rebuttal) with a new serial number • And disable the corresponding ring! • Remove from view those members who’ve been accused for longer than 2 •  is the gossip dissemination time

23. PlanetLab evaluation setup • Configuration • t = 12 (25 monitoring rings) • Gossip rate = 1 gossip / 3.5 seconds • Byzantine members: • 10% aggressive + 10% passive • aggressive attacks: • accuse at any opportunity • do not forward rebuttals • passive attacks: • never accuse • do not forward accusations

24. Protocol overhead on PlanetLab # members bytes/sec

25. What’s still needed? • Mandatory Information Flow • Gossip on need-to-know basis • Eliminate covert channels • Fair Sharing (Congestion Control) • Prevent some from using up all capacity • Secure Aggregation • Much like electronic voting • Everybody counted exactly once • More?

26. Let’s look at use cases first.. • Important timely disseminations that are undesired by some and likely to be attacked • Certificate Revocation Lists • Security patches • Political messages • Needs availability & integrity

27. Use cases, cont’d • Video Streaming on the cheap • Webcasting • tele-conferencing • Entertainment • Needs availability & mandatory information flow & fairness & fair sharing

28. Use cases, cont’d • Monitoring & Auditing • PlanetLab • Cooperative Web Caching • … • Needs secure aggregation & flow control

29. Use cases, cont’d • Replication • Files • Control data • Needs availability & integrity & information flow

30. Valid Accusations • Accusation is valid iff • Accusation is correctly signed by accuser, and • Ring is enabled by the accused, and • Accuser is a monitor of the accused: • Accuser is direct predecessor on a ring, or • holds valid accusations for everybody in between accuser and accused Recursive relation (without base case) complicates correctness proof…

31. Fireflies Group Membership • Group membership protocol • Tolerant of Byzantine failures • Probabilistic… • Provides and uses secure gossip infrastructure Fireflies have on/off behavior and use mimicry to dupe and devour related species…

32. Assumptions • Network can lose messages • But correct members form a connected communication graph of fair links • Byzantine members can collude • But cannot break crypto, and DDoS attacks can be detected and suppressed • Bounded Pbyzantine

33. Informal Insight • Gossip implements something like an atomic broadcast (whp) • Gets around problems associated with asynchrony, such as FLP result • Atomic broadcast can implement consensus, which is approximately what we need here…

34. How to pick t ? Large enough so that the probability of having more than t Byzantine predecessors is smaller than  • = 1/N  E(problem) = 1

35. “max” propagation time ()

36. PlanetLab • Deployed on >150 PlanetLab nodes Disclaimer: PlanetLab results are not repeatable and biased