Post on 24-Dec-2015
transcript
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?