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) o1: ABCE Delete(2) o2: ACDE Delete(4) o1: ABCE Delete(2) o2: ACDE Delete(2) o1: ACE Delete(4) o2: ABD Delete(2) o1: ACE Delete(3) o2: 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) • Key shared with the new client • New client generates current state from Ops stores at server New Shared Key • Old key needed to decrypt updates encrypted using it (new clients) 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???