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