sporc: group collaboration using untrusted cloud resources osdi 2010 presented by yu chen

SPORC: Group Collaborationusing Untrusted Cloud Resources

OSDI 2010Presented by Yu Chen

Cloud-based Collaborative Services

Pros:

-Global accessibility, High availability,

-Fault tolerance,

-Elastic resource allocation and scaling Cons and Problem:

-Sacrifice in security and privacy What if the server is malicious?

Solution: SPORC

Agnostic and untrusted server

- provides a generic collaboration service

- assigns a global order

- stores updates in its encrypted history

- can be potentially MALICIOUS

Solution: SPORC

Smart Clients

-guarantee security by users' cryptographic keys

-provides operational transformation

-provides fork* consistency

-recover from malicious forks

-access the documents on behalf of authorized

users

Goals

Flexible framework for a broad class of collaborative services

Propagate modifications quickly Tolerate slow or discounted networks Keep data confidential Detect a misbehaving server Recover from malicious server behavior

Background: Operational Transformation

Problem: Operations might conflict with each other Example:

State: ABCDE

Alice: op1='del 4' Bob: op2='del 2'

naïve execution:

Alice: ACE Bob:ACD OT enables optimal local updates and eventual

consistency

Background:Operational Transformation

Example:

State: ABCDE

Alice: op1='del 4'; op2' Bob op2='del 2'; op1'

Background: Fork* Consistency

Problem:

Divergent views from misbehaving server Solution:

-Clients share information about the history

-

- Possible partitions into groups, but solvable

Deployment and Threat Model

Deployment

-Large number of users and documents

-Server: replicating functionality and partitioning state

-Client-driven failover and recovery Threat Model

- Server: potentially malicious; unable to corrupt the clients' states

- Client: trusts assigned according to the user; genuine code

System Overview

Invariance in SPORC

Local Coherence:

Starting from an empty state, applying the operations in commited history and pending queue will result in the current state

Fork* Consistency Client-Order Preservation

Operations

Labeled with the name of the user Digitally signed by the user's private key Includes the client ID Document Operations

- encrypted under a symmetric key Meta Operations Why 2 different operations? Solution later.

Sequence Numbers and Hash Chains

Client Sequence Number(clntSeqNo) Global Sequence Number(seqNo)

Last Commited Operation(opn)

Last Commited Operation Number(prevSeqNo) Verification:

- Client order preservation(Efficiency??)

- Fork* consistency

Resolving confliects with OT

Additional Operations from the Server

-seqNo>preSeqNo+1

-op'new ← T(opnew,

<opprevSeqNo+1,...,opseqNo-1>)

Uncommited Operations in the Client's Pending Queue

-

Membership Management

Access Control List

- reader, editor and administrator

- ModifyUserOp Payloads encrypted by AES + users' public keys User Removal: new random AES key Barrier Operation

-Continuous Chain of Keys(or Checkpoints)

Extension: Checkpoint

Supported by individual clients CheckpointOp

- Encryption with current document key

- contains the hash of encrypted checkpoint data Verification of CheckpointOp

- meta-history

Extension: Checking for ForksOut-of-Band

Fork partition created by the server:

-Clients of one fork might never know the history

of clients of another fork Check for Forks Out-of-Band

- Message exchanging between clients

- <c,d,s,hs>

- Request of missing operation from the server

Recovering from a Fork

Recovery via a new server

-Both clients will roll back their histories to their last common point before fork

-One of them upload the common history to the new server

-Both of them will resubmit the operations after the fork

Implementation

generic server client-libraries

-sending, receiving, encryption, OT and consistency checks

Applications:

-Key-value store

-collaborative text editor

Experimentatal Evaluation Hardware

-2.3GHz AMD Opteron

-8GB of RAM

-gigabit switched ethernet Metrics

-Latency

-Server throughput

-Client time-to-join

Latency

Latency

Server Throughput

Client time-to-join

Conclusion

OT enables optimistic updates and reconciles clients' conflicting states

OT and fork* consistency complement each other well

Membership mamangement architecture

Discussion

The extension are not evaluated in this paper Check for Forks Out-of-Band or Recovering from

a Fork:

-What if the client is also malicious?

-How should we prevent the client-server collusion?

What is the mean time to detect a malicious server with no partition of forks and clients?