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