SPORC: Group Collaboration using Untrusted Cloud Resources OSDI 2010 Presented 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(op n ) 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(op new, ) 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 Forks Out-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 - - 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

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?