SPORC: Group Collaboration
using Untrusted Cloud Resources
OSDI 2010
Presented by Yu Chen
Cloud-based Collaborative Services

Pros:
-Global accessibility, High availability,
-Fault tolerance,
-Elastic resource allocation and scaling

Cons and Problem:
-Sacrifice in security and privacy

What if the server is malicious?
Solution: SPORC

Agnostic and untrusted server
- provides a generic collaboration service
- assigns a global order
- stores updates in its encrypted history
- can be potentially MALICIOUS
Solution: SPORC

Smart Clients
-guarantee security by users' cryptographic keys
-provides operational transformation
-provides fork* consistency
-recover from malicious forks
-access the documents on behalf of authorized
users
Goals

Flexible framework for a broad class of
collaborative services

Propagate modifications quickly

Tolerate slow or discounted networks

Keep data confidential

Detect a misbehaving server

Recover from malicious server behavior
Background:
Operational Transformation


Problem: Operations might conflict with each
other
Example:
State: ABCDE
Alice: op1='del 4'
Bob: op2='del 2'
naïve execution:
Alice: ACE

Bob:ACD
OT enables optimal local updates and eventual
consistency
Background:
Operational Transformation

Example:
State: ABCDE
Alice: op1='del 4'; op2' Bob op2='del 2'; op1'
Background:
Fork* Consistency

Problem:
Divergent views from misbehaving server

Solution:
-Clients share information about the history
- Possible partitions into groups, but solvable
Deployment and Threat Model

Deployment
-Large number of users and documents
-Server: replicating functionality and partitioning
state
-Client-driven failover and recovery

Threat Model
- Server: potentially malicious; unable to corrupt
the clients' states
- Client: trusts assigned according to the user;
System Overview
Invariance in SPORC

Local Coherence:
Starting from an empty state, applying the
operations in commited history and pending
queue will result in the current state

Fork* Consistency

Client-Order Preservation
Operations

Labeled with the name of the user

Digitally signed by the user's private key

Includes the client ID

Document Operations
- encrypted under a symmetric key

Meta Operations

Why 2 different operations? Solution later.
Sequence Numbers
and Hash Chains

Client Sequence Number(clntSeqNo)

Global Sequence Number(seqNo)

Last Commited Operation(opn)

Last Commited Operation Number(prevSeqNo)

Verification:
- Client order preservation(Efficiency??)
- Fork* consistency
Resolving confliects with OT

Additional Operations from the Server
-seqNo>preSeqNo+1
-op'
← T(op
,
new
new
<op
,...,op
>)
prevSeqNo+1
seqNo-1

-
Uncommited Operations in the Client's Pending
Queue
Membership Management

Access Control List
- reader, editor and administrator
- ModifyUserOp

Payloads encrypted by AES + users' public
keys

User Removal: new random AES key

Barrier Operation
-Continuous Chain of Keys(or Checkpoints)
Extension: Checkpoint

Supported by individual clients

CheckpointOp
- Encryption with current document key
- contains the hash of encrypted checkpoint data

Verification of CheckpointOp
- meta-history
Extension: Checking for Forks
Out-of-Band

Fork partition created by the server:
-Clients of one fork might never know the history
of clients of another fork

Check for Forks Out-of-Band
- Message exchanging between clients
- <c,d,s,h >
s
- Request of missing operation from the server
Recovering from a Fork

Recovery via a new server
-Both clients will roll back their histories to their
last common point before fork
-One of them upload the common history to the
new server
-Both of them will resubmit the operations after
the fork
Implementation

generic server

client-libraries
-sending, receiving, encryption, OT and
consistency checks

Applications:
-Key-value store
-collaborative text editor
Experimentatal Evaluation

Hardware
-2.3GHz AMD Opteron
-8GB of RAM
-gigabit switched ethernet

Metrics
-Latency
-Server throughput
-Client time-to-join
Latency
Latency
Server Throughput
Client time-to-join
Conclusion



OT enables optimistic updates and reconciles
clients' conflicting states
OT and fork* consistency complement each
other well
Membership mamangement architecture
Discussion


The extension are not evaluated in this paper
Check for Forks Out-of-Band or Recovering
from a Fork:
-What if the client is also malicious?
-How should we prevent the client-server
collusion?

What is the mean time to detect a malicious
server with no partition of forks and clients?