venus verification node for untrusted storage
DESCRIPTION
Venus Verification Node for Untrusted Storage. Project Presentation. Students: Yan Michalevsky Asaf Cidon. Supervisors: Alexander Shraer Assoc. Prof. Idit Keidar. Vision Statement. Users should not blindly “trust the cloud” - PowerPoint PPT PresentationTRANSCRIPT
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