Providing secure storage on the internet
This presentation is the property of its rightful owner.
Sponsored Links
1 / 39

Providing Secure Storage on the Internet PowerPoint PPT Presentation


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

Providing Secure Storage on the Internet. Barbara Liskov & Rodrigo Rodrigues MIT CSAIL April 2005. Internet Services. Store critical state Are attractive targets for attacks Must continue to function correctly in spite of attacks and failures. Replication Protocols.

Download Presentation

Providing Secure Storage on the Internet

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


Providing secure storage on the internet

Providing Secure Storage on the Internet

Barbara Liskov & Rodrigo Rodrigues

MIT CSAIL

April 2005


Internet services

Internet Services

  • Store critical state

  • Are attractive targets for attacks

  • Must continue to function correctly in spite of attacks and failures


Replication protocols

Replication Protocols

  • Allow continued service in spite of failures

    • Failstop failures

    • Byzantine failures

  • Byzantine failures really happen!

    • Malicious attacks


Internet services 2

Internet Services 2

  • Very large scale

    • Amount of state

    • Number of users

    • Implies lots of servers

  • Must be dynamic

    • System membership changes over time


Bft ls

BFT-LS

  • Provide support for Internet services

    • Highly available and reliable

    • Very large scale

    • Changing membership

  • Automatic reconfiguration

    • Avoid operator errors

  • Extending replication protocols


Outline

Outline

  • Application structure

  • MS specification

  • MS implementation

  • Application methodology

  • Performance and analysis


System model

C

C

C

C

S

S

S

S

S

S

Unreliable

Network

System Model

  • Many servers, clients

  • Service state is partitioned among servers

  • Each “item” has a replica group

  • Example applications: file systems, databases


Client accesses current replica group

s

s

s

s

s

s

s

s

s

s

s

s

s

s

s

s

Client accesses current replica group

C


Client accesses new replica group

s

s

s

s

s

s

s

s

s

s

s

s

s

s

s

s

Client accesses new replica group

C


Client contacts wrong replica group

s

s

s

s

s

s

s

s

s

s

s

s

s

s

s

s

Client contacts wrong replica group

C


The membership service ms

The Membership Service (MS)

  • Reconfigures automatically to reduce operator errors

  • Provides accurate membership information that nodes can agree on

  • Ensures clients are up-to-date

  • Works at large scale


System runs in epochs

System runs in Epochs

  • Periods of time, e.g., 6 hours

  • Membership is static during an epoch

  • During epoch e, MS computes membership for epoch e+1

  • Epoch duration is a system parameter

  • No more than f failures in any replica group while it is useful


Server ids

Server IDs

  • Ids chosen by MS

  • Consistent hashing

  • Very large circular id space


Membership operations

Membership Operations

  • Insert and delete node

  • Admission control

    • Trusted authority produces a certificate

  • Insert certificate includes

    • ip address, public key, random number, and epoch range

    • MS assigns the node id ( h(ip,k,n) )


Monitoring

Monitoring

  • MS monitors the servers

    • Sends probes (containing nonces)

    • Some responses must be signed

  • Delayed response to failures

  • Timing of probes, number of missed probes, are system parameters

  • BF nodes (code attestation)


Ending epochs

Ending Epochs

  • Stop epoch after fixed time

  • Compute the next configuration:

    Epoch number

    Adds and Deletes

  • Sign it

    • MS has a well known public key

  • Propagated to all nodes

    • Over a tree plus gossip


Guaranteeing freshness

C

MS

Guaranteeing Freshness

  • Clients sends a challenge to MS

  • Response gives client a time periodT during which it may execute requests

  • T is calculated using client clock

<nonce>

<nonce, epoch #>σMS


Implementing the ms

Implementing the MS

  • At a single dedicated node

    • Single point of failure

  • At a group of 3f+1

    • Running BFT

    • No more than f failures in system lifetime

  • At the servers themselves

    • Reconfiguring the MS


System architecture

System Architecture

  • All nodes run application

  • 3F+1 run the MS


Implementation issues

Implementation Issues

  • Nodes run BFT

    • State machine replication (e.g., add, delete)

  • Decision making

  • Choosing MS membership

  • Signing


Decision making

Decision Making

  • Each replica probes independently

  • Removing a node requires agreement

    • One replica proposes

    • 2F+1 must agree

    • Then can run the delete operation

  • Ending an epoch is similar


Moving the ms

Moving the MS

  • Needed to handle MS node failures

  • To reduce attack opportunity

    • Move must be unpredictable

  • Secure multi-party coin toss

  • Next replicas are h(c,1), …, h(c,3F+1)


Signing

Signing

  • Configuration must be signed

  • There is a well-known public key

  • Proactive secret sharing

  • MS replicas have shares of private key

    • F+1 shares needed to sign

  • Keys are re-shared when MS moves


Changing epochs summary of steps

Changing Epochs: Summary of Steps

  • Run the endEpoch operation on state machine

  • Select new MS replicas

  • Share refreshment

  • Sign new configuration

  • Discard old shares


Example service

Example Service

  • Any replicated service

  • Dynamic Byzantine Quorums dBQS

    • Read/Write interface to objects

  • Two kinds of objects

    • Mutable public-key objects

    • Immutable content-hash objects


Dbqs object placement

dBQS Object Placement

  • Consistent hashing

  • 3f+1 successors of object id are responsible for the object

14

16


Byzantine quorum operations

Byzantine Quorum Operations

  • Public-key objects contain

    • State, signature, version number

  • Quorum is 2f+1 replicas

  • Write:

    • Phase 1: client reads to learn highest v#

    • Phase 2: client writes to higher v#

  • Read:

    • Phase 1: client gets value with highest v#

    • Phase 2: write-back if some replicas have a smaller v#


Dbqs algorithms dynamic case

dBQS Algorithms – Dynamic Case

  • Tag all messages with epoch numbers

  • Servers reject requests for wrong epoch

  • Clients execute phases entirely in an epoch

    • Must be holding a valid challenge response

  • Servers upgrade to new configuration

    • If needed, perform state transfer from old group

  • A methodology


Evaluation

Evaluation

  • Implemented MS, two example services

  • Ran set of experiments on PlanetLab, RON, local area


Ms scalability

MS Scalability

  • Probes – use sub-committees

  • Leases – use aggregation

  • Configuration distribution

    • Use diffs and distribution trees


Fetch throughput

Fetch Throughput


Time to reconfigure

Time to reconfigure

  • Time to reconfigure is small

  • Variability stems from PlanetLab nodes

  • Only used F = 1, limitation of APSS protocol


Dbqs performance

dBQS Performance


Failure free computation

Failure-free Computation

  • Depends on no more than F failures while group is useful

  • How likely is this?


Providing secure storage on the internet

Probability of Choosing a Bad Group


Probability of choosing a bad group

Probability of Choosing a Bad Group


Probability that the system fails

Probability that the System Fails


Conclusion

Conclusion

  • Providing support for Internet services

  • Scalable membership service

    • Reconfiguring the MS

  • Dynamic replication algorithms

    • dBQS – a methodology

  • Future research

    • Proactive secret sharing

    • Scalable applications


Providing secure storage on the internet1

Providing Secure Storage on the Internet

Barbara Liskov and Rodrigo Rodrigues

MIT CSAIL

April 2005


  • Login