Masoud ValafarCloud Overview Advantages: Scalability/availability Pay-on-demand Minimizing in house infrasructure Challenge: Security Privacy Integrity consistencyWhere does this work fit? Addressing integrity and consistency of data – approaches: From within the clouds From Outside the clouds Venus assures  Integrity: a data object read by any client is previously written by another client (protection against malicious provider) Consistency: allowing multiple clients to access data concurrently in a consistent fashion Goals: Clients dynamics Clients do their operation independently No additional trusted component needed  Works on normal cloud commodityContributions and assumptions Contributions Providing cryptographic integrity and consistency without introducing trusted component Does not involve client-to-client coordination Simple semantics for clients – allowing optimistic operation execution and providing consistency later Implementation Assumptions: No malicious client (providing security against cloud) A number of clients (in the core set) don’t crashVENUS Structure Commodity storage service Verifier – hosted in the cloud, may become faulty Clients Read Write Core set – publicly known, help detecting consistency and failures, manage client membershipVENUS Design Optimism! Advantage: clients can work concurrently clients do their job (integrity ensured), check for consistency problem Causal consistency is ensured to Question: What happens after an erroneous operation? Asynchronous call back interface Issues periodic consistency and failure notification VENUS ensures existence of a global sequence of operations, in which legal operations appears according to their order of execution Legal: every read returns the value written by the last write (or failure if no object exist) Sequence includes green operations of all clients VENUS guarantees complete operations either become legal or will be detected if failWrite Operation Client Writing in  Waits for Ack (to make sure it doesn’t crash) Send submit , and to verifier  Verifier creates a ordered list of submit messages, a global sequence of operationsiCxxpxhxpRead Operation Client asks for object  Verifier responds with Client gets the object and checks the hash It will return fail if doesn’t exist or hash doesn’t matchxp),(xxhpxpConsistency/Integrity How can we make sure that and correspond to the latest write operation In order to verify operations we need which is consisted of pair  Verifier supplies the context of operations context of operation is the prefix of up to operation as determined by executer of the operation before completes , it determines its vector-clock, that contains the timestamp of the latest operation of in the j-th entry contains the cryptographic hash of the prefix of up to that operationxpxhooiCo)(ovcjC)(oversion))(),(( ovhovc)(ovhConsistency/Integrity (2) Order on versions:  (for every k, )  For every k that , )()( oversionoversion)()( ovcovc])[(])[( kovckovc])[(])[( kovckovc])[(])[( kovhkovhConsistency/Integrity (3) Information that verifier keeps ,an array that contains the last version received from each client , the index of the client from which the maximal version was received , list of pending operations , contains an array of proofs from SUBMIT messages , containing tuples received if the last operations of a client is a write  Verifier sends , , ,  If the operation is read also, from the last pending write operation, other wide from VercPe nd ingproofsPathsc)(coversionPe nd ingproofs),,(xxxthpPathsConsistency/Integrity (4) Information that clients keep Information of the last operation and (if the last operation is read) Client actions Checking hashes and signatures  Checking  if operation is read, then checking with corresponding item in or  Client computes and checks with returned version There is at most one operation for each client in  Checking timestamps of each operation in pending so that it is the last operation of that client Validity of proof for each client that has an operation in pending –proof contain the valid signature of clients on their last operationsprevoprevpprevh)()(prevcoversionovers ionxtPe nd ing)(cots)(oversionPe nd ingConsistency/Integrity (5) Clients also keep which contains the last version of each client To get the latest versions: Refresh it via verifier: actual clients activities or dummy-reads Client-to-client communication (whenever a client executes an operation) Clients updates their entries and check whether their operations go green by majority (core-set) checking Failures will be broadcasted to core sets, and they broadcast it to other clientsCVerCVerOptimization Do all the checks when receiving dummy-submit reply If both replies are the same, then move on Need garbage collection due to creating dummy objectsDynamic Join Clients have global identifiers Clients in core sets need to know the public key of new clients Informing a client about other clients (for checking signatures)Implementation implementation HTTP based communication to S3 Clients communicate through email GnuPG for signatureEvaluation Average operation latency for a single client executing operations (using just one client) The overhead of using VENUS depends on the location of verifierEvaluation (2) 10 clients, 3 in the core, half do read and half do write, each 50 operations Fig. 11 shows average time for an operation to complete The average latency depends on the inter-invoke latency because versions advance in a slower rateEvaluation (3) Amazon S3 does not support pipelining HTTP requests, therefore, throughput is number of client threads over average operation latency Throughput of VENUS is identical to raw S3Goals revisited Goals: Dynamic client participation No additional trusted component needed (what about users in core-set?) Works on normal cloud commodity Clients do their operation independently Other issues: How to recover from an error Malicious users Overhead in