SPORC: Group Collaboration Solution for Cloud-Based Services

SPORC: Group Collaboration using Untrusted Cloud Resources Ariel J. Feldman, William P. Zeller, Michael J. Freedman, Edward W. Felten Published in OSDI 2010. Presented by Cintia Silva Sandeep Vasani

Cloud Based Services Pros Global accessibility, High availability Fault tolerance Elastic resource allocation and scaling Con Fully trusted servers are high value targets for server attacks Must we sacrifice security and privacy to enjoy the benefits of cloud deployment?

Solution: SPORC Generic Centralized Solution Cloud based system which allows group collaboration services without requiring to trust your cloud provider Server: untrusted, assigns global order, stores updates in encrypted history, can be malicious Clients: handles security using Cryptographic Primitives, does conflict resolution and recover from malicious servers

Goals Flexible framework for a broad class of collaborative services Propagate modifications quickly Tolerate slow or discounted networks Keep data confidential from server Detect a misbehaving server Recover from malicious server behavior

Problem 1: Consistency Solution for consistency in optimistic replication through Operational Transform Client 1 Client 2 Client 1 Client 2 o1: ABCDE o2: ABCDE o1: ABCDE o2: ABCDE Delete(4) Delete(2) Delete(4) Delete(2) o1: ABCE o2: ACDE o1: ABCE o2: ACDE Delete(3) Delete(2) Delete(4) Delete(2) o1: ACE o2: ACE o2: ABD o1: ACE After the two operations, object view at the clients o1 and o2 different After the applying OT , object view at the clients o1 and o2 same

Problem 2: Malicious Servers Clients communicating via untrusted server: they may be provided with different views Fork* consistency guarantees that server misbehavior is detected within 1 fork (partition)

Data Structure Server maintains: Encrypted history of operations Client maintains: Document state (application-view) Committed history of operations (maintains hash chain of committed operations) Pending queue of uncommitted operations Document state includes both history and queue.

System Design Invariant 1: Local Coherence Invariant 2: Fork* Consistency Invariant 3: Client-Order Preservation

Operations Client Exchange two types of operations: Document operation: changes to the content of the document Meta-operations: changes to Access Control List(ACL) ACL user rights: reader, writer, admin Symmetric Key Maintenance is done via users with admin right without server s involvement

Membership Management Shared Key (for efficiency) New Shared Key Old key needed to decrypt updates encrypted using it (new clients) Key shared with the new client New client generates current state from Ops stores at server

Implementation generic server client-libraries based on application type sending, receiving, encryption, OT and consistency checks Authors have discussed the following applications: Key-value store collaborative text editor

Evaluation One server, four machines with multiple clients All machines were connected by gigabit switched Ethernet Two configurations: Low Load: Single client sends operation High Load: Every client sends operation Metrics: Latency: In-flight time Server throughput Client time-to-join

Latency (1/2) Low Load Text Editor Server processing increases as broadcast to more clients Client overhead nearly constant

Latency (2/2) High Load Text Editor Client queuing increases with more clients Server Processing also increases

Server Throughput More payload => More processing/packet More payload => Processing overhead/byte decreases

Time to Join

Related Work Google Wave: Centralized trusted server Uses OT for conflict resolution does not make use of Fork* consistency Like in SPORC only allows one operation in flight at once Bayou: Decentralized P2P system Application need to specify conflict detection and resolution protocol as an alternative to OT Venus: Only for key-value stores Requires a core set of clients to be online Membership can t be revoked Depot: Applications-logic for conflict resolution Client eq. to server, can also tolerate faulty clients

Discussion (1/2) Is the server needed at all? Limited role: Assign increasing sequence number to updates clients receive updates in the same order (TCP used). Store history Required for timely notification and to achieve cloud based deployment Server attack to availability What if the server fails?

Discussion (2/2) How long will it take to detect a malicious server? Crucial for overall system performance analysis but not discussed or evaluated in the paper How to recover from fork? Use out of band client communication What if client is malicious? Can happen and whole system fails They haven t benchmarked their system to others using the same principles.

Future Work Detecting forks through out-of-band communication Supporting checkpoints to reduce the size of storing committed history Evaluating mean time it takes to detect a malicious server

Conclusion SPORC achieves cloud deployment benefits without sacrificing security and privacy with the use of untrusted servers. Combines OT and Fork* Consistency protocol to preserve consistency and converge to common shared state. System as such is still not completely secured against server availability attacks, malicious clients and server partition of clients.

Thank You Questions???