Project Presentation Students: Yan Michalevsky Asaf Cidon Supervisors: Alexander Shraer Assoc. 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

 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 23 rd 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, mpel_salesforce.fortune/index.htm mpel_salesforce.fortune/index.htm  “Fail-Aware Untrusted Storage”, C. Cachin, I. Keidar, A. Shraer, 2009  Additional references included in article citations section