Upload
celeste-grisson
View
218
Download
1
Tags:
Embed Size (px)
Citation preview
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???