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 1Client 2 o1: ABCDEo2: ABCDE o1: ABCEo2: ACDE o1: ACE o2: ABD Delete(4) Delete(2) Delete(4)Delete(2) 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 Client 1Client 2 o1: ABCDEo2: ABCDE o1: ABCEo2: ACDE o1: ACEo2: ACE Delete(4) Delete(2) Delete(3) Delete(2)

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 New Shared Key Shared Key (for efficiency) 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) “Client queuing” increases with more clients “Server Processing” also increases High Load Text Editor

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