1 / 26

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

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

andrew-slater
Download Presentation

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

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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(opn) • 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(opnew, <opprevSeqNo+1,...,opseqNo-1>) • 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 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

  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

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

More Related