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


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

What’s the scuttlebutt on Secure Gossip?

Robbert van Renesse


Secure gossip or gossip for security

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

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

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

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

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

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 3 minsky schneider

    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

    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 johansen foo gossip fireflies ordered rings

    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 renesse securestream

    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

    Li, Alvisi et al.BAR gossip

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

      (See RFC3092 for FOOBAR origins)


    Fireflies gossip

    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

    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

    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

    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

    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

    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

    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

    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


    Data structures

    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

    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

    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

    Protocol overhead on PlanetLab

    # members

    bytes/sec


    What s still needed

    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

    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

    Use cases, cont’d

    • Video Streaming on the cheap

      • Webcasting

      • tele-conferencing

      • Entertainment

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


    Use cases cont d1

    Use cases, cont’d

    • Monitoring & Auditing

      • PlanetLab

      • Cooperative Web Caching

    • Needs secure aggregation & flow control


    Use cases cont d2

    Use cases, cont’d

    • Replication

      • Files

      • Control data

    • Needs availability & integrity & information flow


    Valid accusations

    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

    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

    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

    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

    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

    “max” propagation time ()


    Planetlab

    PlanetLab

    • Deployed on >150 PlanetLab nodes

      Disclaimer: PlanetLab results are not repeatable and biased


  • Login