1. Project Presentation Students: Yan Michalevsky Asaf Cidon Supervisors: Alexander Shraer Assoc. Prof. Idit Keidar

2.  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

4.  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

5.  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

6.  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

7.  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

8.  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?

9.  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)

10.  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

11.  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!)

13.  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

14.  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

15.  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

16.  Learn about distributed computing research  Implement client-to-client communication  Deploy verification node on Google Web Apps  Assist in writing the article

17.  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

18.  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

19.  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 23 rd 2009

20.  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/he mpel_salesforce.fortune/index.htm http://money.cnn.com/2009/02/16/technology/he mpel_salesforce.fortune/index.htm  “Fail-Aware Untrusted Storage”, C. Cachin, I. Keidar, A. Shraer, 2009  Additional references included in article citations section