Project Presentation

Students:Yan MichalevskyAsaf Cidon

Supervisors: Alexander ShraerAssoc. Prof. Idit Keidar

Users should not blindly “trust the cloud”

Users should have tools that guarantee integrity and consistency for data they store in online storage systems

Utilize research on untrusted storage for real-world mass-market applications

Many providers now offer wide-variety of online data storage services, a.k.a. clouds:

◦ Software Collaboration◦ Social Networking◦ Online Archiving◦ Document Repositories◦ Open Source Development

Large corporations and SMEs have started utilizing Clouds in order to save IT infrastructure costs

Online IT service providers also provide cloud-enabled products

◦ SalesForce.com◦ Oracle◦ SAP

Multiple risks in releasing data to online platforms:

◦ Loss of privacy◦ Lack of availability◦ Data corruption◦ Data inconsistencies between multiple clients◦ Exposure to malicious online attacks◦ Unauthorized access

Byzantine fault-tolerant (BFT) replication protocol◦ Capable of guaranteeing integrity & consistency

If used by a storage provider◦ Need at least 2/3 correct servers on the cloud

But most servers located in the same place, run the same system

guaranteeing that servers fail independently would be very costly

◦ Require high communication overhead Providers prefer weaker consistency

◦ Cloud providers do not currently implement BFT protocols◦ Most importantly: clients would still need tools to check

provider behavior and should not simply “trust the cloud” If used by the client

◦ Store data on multiple (at least 4) storage providers costly to the client

Store a hash of the data locally◦ Allows clients to verify server responses◦ Use hash-trees when volume of data is large

(store locally the root of the hash-tree)

Proofs of Retrievability (PORs) ◦ Allows a client to verify that the server stores its

data without reading all the data

What about multiple clients?

Strong consistency (atomicity, sequential consistency) ◦ not possible, assuming we want clients to be able

to execute operations independently of each other

◦ Server can hide latest write from readers◦ Server can split its brain (each client thinks he

executes in isolation)

Fork-Consistency Advantages:

Linearizable view of a sub-sequence of the execution After the server lies, if clients see new information

from each other, they detect inconsistency

Disadvantages Blocking, even when server is correct

A weaker consistency was devised in order to enable a wait-free protocol.

Example:

◦ In Fork-Consistency, if C1 crashed during w1, C2 would be blocked while conducting r2 (even though the server was telling the truth!)

A common cloud-computing scenario:

◦ Multiple clients working concurrently◦ Using a commodity online storage provider (e.g.

Amazon S3, Salesforce.com Force)

Our goal:◦ Integrity and eventual consistency for client data◦ Detection of inconsistencies / service failures

Concept:

◦ An untrusted verification node, can quickly detect inconsistencies when it is not faulty

◦ Clients communicate directly when they suspect that storage or verifier is faulty

◦ Clients can use any unmodified commodity cloud storage provider

Features:

◦ Operations are conducted optimistically wait-free

◦ Clients can go offline, new clients can join◦ All clients receive failure notifications when

consistency breach is detected◦ Operations eventually become consistent

clients know up to which point the data is consistent with other clients

Learn about distributed computing research

Implement client-to-client communication

Deploy verification node on Google Web Apps

Assist in writing the article

E-mail based

Authenticated (using GNUPG)

A client communicates directly with another:◦ To request and send status updates, if no recent

activity of that client was seen on storage◦ When an inconsistencies is detected

Verification node was initially deployed on Google Web Apps and used HTTP to communicate with Clients

We realized that Google Web Apps is not appropriate for hosting the verification node

◦ The verification node creates a sequence of client requests◦ Maintaining such sequence with Google Apps is very costly

Instead, verifier was deployed on a regular server in MIT

We wrote the initial versions of the Introduction and Related Works sections

Contributed to the System Design and Deployment and Implementation sections

Article was submitted to Eurosys2010 in October 23rd 2009

Too many to list on this slide “Trusting the Cloud”, C. Cachin, I. Keidar, A.

Shraer, 2009 “Towards a Cloud Computing Research Agenda”,

K. Birman, G. Chockler, R. van Renesse, 2009 “Salesforce hits its stride”, J. Hempel, Fortune

Magazine, http://money.cnn.com/2009/02/16/technology/hempel_salesforce.fortune/index.htm

“Fail-Aware Untrusted Storage”, C. Cachin, I. Keidar, A. Shraer, 2009

Additional references included in article citations section