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
Dec 14, 2015
SPORC: Group Collaboration using Untrusted Cloud Resources
Ariel J. Feldman, William P. Zeller, Michael J. Freedman, Edward W. Felten Published in OSDI’2010.
Presented byCintia 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 TransformClient 1 Client 2
o1: ABCDE o2: ABCDE
o1: ABCE o2: 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 1 Client 2
o1: ABCDE o2: ABCDE
o1: ABCE o2: ACDE
o1: ACE o2: 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 KeyShared 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???