What s the scuttlebutt on secure gossip
This presentation is the property of its rightful owner.
Sponsored Links
1 / 36

What’s the scuttlebutt on Secure Gossip ? PowerPoint PPT Presentation


  • 139 Views
  • Uploaded on
  • Presentation posted in: General

What’s the scuttlebutt on Secure Gossip ?. Robbert van Renesse. Secure Gossip or Gossip for Security?. Secure gossip: making sure probabilistic guarantees hold in the face of malicious behavior

Download Presentation

What’s the scuttlebutt on Secure Gossip ?

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


What’s the scuttlebutt on Secure Gossip?

Robbert van Renesse


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?


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


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


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


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…


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


  • 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…


    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


    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


    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


    Li, Alvisi et al.BAR gossip

    • Elegant game-theoretic approach to dealing with rational and Byzantine nodes

      (See RFC3092 for FOOBAR origins)


    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


    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


    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


    Working out the math…

    • k : out degree

    • N : correct + Byzantine members

    • n : correct members

    • : probability of graph being connected

      But what about crashed members???


    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…


    Protocol Structure

    Accuse and rebut

    Deliver within 

    Membership

    Gossip

    Pinging

    Set Reconciliation

    Monitor and suspect

    Exchange diffs

    EACH COMPONENT IS

    PROBABILISTIC


    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)


    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


    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


    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


    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


    Protocol overhead on PlanetLab

    # members

    bytes/sec


    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?


    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


    Use cases, cont’d

    • Video Streaming on the cheap

      • Webcasting

      • tele-conferencing

      • Entertainment

    • Needs availability & mandatory information flow & fairness & fair sharing


    Use cases, cont’d

    • Monitoring & Auditing

      • PlanetLab

      • Cooperative Web Caching

    • Needs secure aggregation & flow control


    Use cases, cont’d

    • Replication

      • Files

      • Control data

    • Needs availability & integrity & information flow


    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…


    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…


    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


    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…


    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


    “max” propagation time ()


    PlanetLab

    • Deployed on >150 PlanetLab nodes

      Disclaimer: PlanetLab results are not repeatable and biased


  • Login