1. SPORC: Group Collaboration using Untrusted Cloud Resources OSDI 2010 Presented by Yu Chen

2. 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?

3. 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

4. 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

5. 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

6. 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

7. Background: Operational Transformation Example: State: ABCDE Alice: op1='del 4'; op2' Bob op2='del 2'; op1'

8. Background: Fork* Consistency Problem: Divergent views from misbehaving server Solution: -Clients share information about the history - - Possible partitions into groups, but solvable

9. 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

10. System Overview

11. 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

12. 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.

13. 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

14. 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 -

15. 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)

16. Extension: Checkpoint Supported by individual clients CheckpointOp - Encryption with current document key - contains the hash of encrypted checkpoint data Verification of CheckpointOp - meta-history

17. 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

18. 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

19. Implementation generic server client-libraries -sending, receiving, encryption, OT and consistency checks Applications: -Key-value store -collaborative text editor

20. Experimentatal Evaluation Hardware -2.3GHz AMD Opteron -8GB of RAM -gigabit switched ethernet Metrics -Latency -Server throughput -Client time-to-join

21. Latency

23. Server Throughput

24. Client time-to-join

25. Conclusion OT enables optimistic updates and reconciles clients' conflicting states OT and fork* consistency complement each other well Membership mamangement architecture

26. 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?