Venus Verification Node for Untrusted Storage

1. VenusVerification Node for Untrusted Storage Project Presentation Students: Yan Michalevsky Asaf Cidon Supervisors: Alexander Shraer Assoc. Prof. Idit Keidar

2. Vision Statement • 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

3. Introduction

4. Cloud Computing • 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. Cloud Computing • 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. Risks and Challenges • 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. Possible Solutions • 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. Possible Solutions For 1 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?

9. Multiple users – Types of Consistency • 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. Possible Solutions • 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. Weak-Fork Consistency • 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!)

12. Project Details

13. What We Are Solving • 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. The Solution: Venus • 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. The Solution: Venus • 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. Project Goals • Learn about distributed computing research • Implement client-to-client communication • Deploy verification node on Google Web Apps • Assist in writing the article

17. Client-to-client Communication • 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. Deployment on Google Web Apps • 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. Explaining Venus: The Article • 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

20. Main References • 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

21. THANK YOU