Protocols for Secure Cloud Computing (Parts 3 and 4)

Transcription

1 School on Applied Cryptographic Protocols 2010 Christian Cachin, IBM Research - Zurich CASED & ECRYPT II cca/ Protocols for Secure Cloud Computing (Parts 3 and 4) 3 Proofs of storage 3.1 Model Consider a client C storing data on a storage provider S. The data is a large file, modeled as a vector x = [x 1,..., x n ] of n blocks of B bits each, i.e., x i Σ B using Σ = {0, 1}. The client writes x to S and wishes to read it later, perhaps multiple times, so that C does not have to store x locally. However, S is not fully trusted and C suspects that it might have accidentally lost or maliciously deleted some parts of x. In this scenario, a proof-of-storage protocol convinces the client that S still stores all its data. The client obtains a cryptographically strong guarantee for this fact, in the sense that whenever it accepts a valid proof, then with overwhelming probability, either S still stores the file and the client can recover the complete file from multiple valid proofs, or S has violated a cryptographic hardness assumption. Of course, the client could simply read a random subset of blocks from x, compute their hash values, and compare them to locally stored copies of the hashes of all blocks, and become convinced that S stores the file. However, this costs a lot of bandwidth and local storage (proportional to n). A cryptographic proof-of-storage protocol achieves the same, but with a practically constant amount of communication and local storage, in comparison to n. More precisely, for a security parameter k with B = O(k) and k = O(log n), the communication size and the local storage are polynomial in k, perhaps even linear in k. We model all algorithms as probabilistic polynomial-time (PPT) algorithms in k. The proof-of-storage protocol relies on a public-key/private key pair of the client. Since the private key is not required for the verification operation, it is a publicly verifiable proof of storage. In the protocol description, we use an n-element vector ȳ whose entries are tuples of the form y i = (x i, τ i ); for the vectors x and τ consisting of all x i and τ i, respectively, we write ȳ = ( x, τ) interchangeably. Definition 1 (Proof-of-storage protocol (P)). A proof-of-storage protocol is an interactive protocol between a client C and a storage provider S. It consists of a quintuple of PPT algorithms P = (Setup, Encode, Challenge, Prove, Verify) such that: (pk, sk) Setup(k) is a probabilistic algorithm that takes as input the security parameter and outputs a public-key/private-key pair. C receives pk and sk, and S receives pk. (ȳ, st) Encode(pk, sk, x) is run by C to obtain an encoded file ȳ and local state st. For simplicity, we assume that every entry of ȳ contains the original block from x together with a tag. In other words, y i = (x i, τ i ) for i = 1,..., n, where x i and τ i are the original block and the tag, respectively. 1

2 C sends ȳ = ( x, τ) to S and S stores it. d Challenge(k) is run by C and outputs a random challenge d R Σ k. C sends d to S. π Prove(pk, ( x, τ), d) is a probabilistic algorithm run by S, upon receiving a challenge, which computes a proof π from the stored encoded file. S sends π to C. Verify(pk, st, d, π) {FALSE, TRUE} is a deterministic algorithm run by C after receiving the proof. Its output indicates whether the proof is valid, in other words, whether the client accepts the proof or not. The protocol satisfies a completeness and a security property: Completeness: For all (pk, sk) output by Setup, for all files x [Σ k ] n, for any ȳ = ( x, τ) and st output by Encode(pk, sk, x) and all d Σ k, it holds Verify ( pk, st, d, Prove(pk, ( x, τ), d) ) = TRUE. Security: Let the adversary A = (A 1, A 2 ) consist of two PPT algorithms. Algorithm A 1 models actions of a malicious provider against a correct client to prepare a forgery, and A 2 plays the role of forging a proof. In the following experiment, which is run between (A 1, A 2 ) and a ring master R, there exists a knowledge extractor (or simulator) E that interacts with A 2 : 1. R computes (pk, sk) Setup(k) and gives pk to A 1 ; 2. A 1 repeatedly outputs some x ; for each one, R computes ȳ Encode(pk, sk, x ), and returns ȳ to A 1 ; 3. A 1 outputs file x and some state a intended for A 2 ; 4. R computes (ȳ, st) Encode(pk, sk, x ); 5. E receives inputs pk and st and interacts with A 2 (a, ȳ, st) as prover, where E may repeatedly query A 2 with challenges and receives the corresponding proofs; 6. Finally E outputs a challenge/proof pair (d, π ) and a file x. Then the probability that Verify(pk, st, d, π ) = TRUE and x x is negligible. The security property ensures that whenever an adversarial provider succeeds in generating valid proofs with non-negligible probability, then the corresponding file can be reconstructed from its answers. Proofs of storage were introduced simultaneously by Ateniese et al. [ABC + 07] and by Juels and Kaliski [JK07]. The model and constructions given here follow the work of Ateniese et al. [AKK09]. 2

3 3.2 Simple implementation A straightforward scheme for implementing an intuitive notion of a storage proof could be the following. It does not satisfy the above definition, however. The client initially gives the key κ for a message-authentication code (MAC) to the provider. Before storing file x, the client uses a pseudo-random generator to derive m random subsets of block indices L 1,..., L m (with L j {1,..., n}) from a seed s. It then pre-computes the authentication tags τ j = authenticate(κ, i Lj x i ) over the concatenated blocks in L j, for j = 1,..., m, and stores the tags. Subsequently, C challenges S with a subset L j in the j-th iteration (note it can reconstruct L j from s). The client expects S to respond with the correctly computed tag over the blocks indicated by L j. When it receives a proof, C compares it to the locally stored tag τ j. The scheme has two shortcomings. First, since the number m is determined a priori, only a fixed number of proofs can be executed once a file has been stored. Furthermore, the client cannot extract the stored data from the proofs. Although these deficiencies may be acceptable for certain practical applications, the scheme is clearly not a secure proof-of-storage protocol as introduced above. 3.3 Implementation from a homomorphic identification protocol We now show how to implement a proof-of-storage protocol that satisfies Definition 1, based on the existence of an identification protocol with a homomorphic property Homomorphic identification protocols Identification protocols are related to proof-of-knowledge protocols; they primarily serve for authenticating an entity to a server without leaking information to an observer. Definition 2 (Identification protocol (I)). An identification protocol is an interactive threemove protocol between a prover P and a verifier V, consisting of a quintuple of PPT algorithms I = (Setup, Commit, Challenge, Respond, Verify): (pk, sk) Setup(k) is a probabilistic algorithm that takes as input the security parameter and outputs a public-key/private-key pair. P receives pk and sk, and V receives pk. t Commit(pk, ρ) is a deterministic algorithm run by P with a random string ρ input, which outputs a commitment t. P sends t to V. c Challenge(k) is a probabilistic algorithm run by V that outputs a challenge c (This models a so-called public-coin proof.) V sends c to P. R Σ k as R Σ k. s Respond(pk, sk, ρ, c) is a probabilistic algorithm run by P that outputs a response s. P sends s to V. 3

4 Verify(pk, t, c, s) {FALSE, TRUE} is a deterministic algorithm run by V after receiving the response. Its output indicates whether the verifier accepts the proof of identification or not. A triple (t, c, s) is called a transcript of the protocol. The algorithms satisfy a completeness and an unforgeability property: Completeness: For all (pk, sk) output by Setup, all k-bit strings ρ and c, it holds Verify ( pk, Commit(pk, ρ), c, Respond(pk, sk, ρ, c) ) = TRUE. Unforgeability: Consider any PPT adversary A that acts as impersonator and runs the following experiment with a challenger C: 1. C computes (pk, sk) Setup(k) and gives pk to A; 2. A repeatedly outputs some c ; for each one, C chooses ρ randomly, computes s Respond(pk, sk, ρ, c ), and returns (ρ, s ) to A; 3. A outputs a forgery transcript ( t, c, s). Then the probability that c differs from all c used in step 2 and Verify(pk, t, c, s) = TRUE is negligible. In a homomorphic identification protocol, there exist additional algorithms for verifying multiple proofs in one step. Any combined set of transcripts (commitments, challenges, and responses) can be verified at once, using a linear combination of the challenges with a vector w = [w 1,..., w n ]. The adversary may obtain valid transcripts as before and combine them as it wishes. The protocol is secure when any valid forgery output by A results only from a linear combination with known challenges. Definition 3 (Homomorphic identification protocol (HI)). A homomorphic identification protocol is an identification protocol, for which there exist two additional algorithms Combinet and Combine-s that satisfy the following completeness and unforgeability properties: Completeness: For all (pk, sk) output by Setup, all vectors of k-bit strings w, and all transcript vectors ( t, c, s) such that Verify(pk, t i, c i, s i ) = TRUE for i = 1,..., n, it holds ( Verify pk, Combine-t( w, t), n i=1 ) w i c i, Combine-s( w, s) = TRUE. Unforgeability: Consider any PPT adversary A that runs the following experiment with a challenger C: 1. C computes (pk, sk) Setup(k) and gives pk to A; 2. A repeatedly outputs some c ; for each one, C chooses ρ randomly, computes s Respond(pk, sk, ρ, c ), and returns (ρ, s ) to A; 3. A outputs a challenge vector c; for i = 1,..., n, C chooses ρ i randomly, computes t i Commit(pk, ρ i ) and s i Respond(pk, sk, ρ i, c i ), and gives ( ρ, t, s) to A. 4

5 4. A outputs a forgery ( w, µ, s), where w = [ w 1,..., w n ] are the combination coefficients. Then the probability that µ n i=1 w ic i and Verify ( pk, Combine-t( w, t), µ, s ) = TRUE is negligible. The Guillou-Quisquater identification protocol [GQ88] and the identification scheme of Shoup [Sho99], both based on the hardness of factoring, are homomorphic and secure according to Definition 3. Shacham and Waters [SW08] construct a proof-of-storage protocol, which contains a suitable homomorphic identification protocol based on bilinear groups Proof-of-storage implementation We now construct a proof-of-storage protocol P from a homomorphic identification protocol HI. The algorithm is illustrated in Algorithm 1. Its basic idea is to have the client compute a HI-response s i from every file block x i of the file, for i = 1,..., n, during encoding and before storing the file. The block is taken as the HI-challenge; the randomness ρ i required in HI for computing the commitment and the response is derived deterministically with an ideal random function H from a seed u. The provider stores s i as the authentication tag for the block, and may also learn u. During the proof step of P, the client asks for a fresh random combination of the HIidentification transcripts, specified by a vector w; the proof returned by S consists of the linear combination µ of the challenges with w and the combination π of the HI-responses with w. The vector w is represented compactly, by deriving it deterministically from the seed d of a pseudo-random function F. The random function H must be modeled as a random oracle for proving the scheme secure. Intuitively, the unforgeability property of HI requires the provider to compute any valid response from blocks of the actual file. 5

6 Algorithm 1 Homomorphic proof of storage. Implements: Proof of storage protocol (P); Uses: Homomorphic identification protocol (HI); function Setup(k) (pk, sk) HI.Setup(k); return (pk, sk); function Encode(pk, sk, x) u R Σ k ; for i {1,..., n} do ρ i H(u i); // t i = HI.Commit(pk, ρ i ) can be reconstructed from u s i HI.Respond(pk, sk, ρ i, x i ); return (( x, s), u); function Challenge(k) d Σ k ; return d; function Prove(pk, ( x, s), d) for i {1,..., n} do w i F d (i); µ n i=1 w ix i ; λ Combine-s( w, s); return (µ, λ); function Verify(pk, u, d, (µ, λ)) for i {1,..., n} do w i F d (i); ρ i H(u i); t i HI.Commit(pk, ρ i ); return HI.Verify(pk, Combine-t( w, t), µ, λ); 6

7 4 Intrusion tolerance through replication A promising approach to securing critical services lies in distributing the service over a set of geographically and organizationally separated replicas. By using so-called Byzantine-fault tolerant (BFT) coordination algorithms to keep the replicas logically synchronized, the failure or even the malicious corruption of some components can be tolerated. Such systems are also called intrusion-tolerant. The protocols usually assume that replicas fail independently of each other. Cloud computing offers an economically attractive way to build and run independent implementations of a service their interfaces are standardized (virtual machines of a certain operating system, simple key-value storage services, etc.) and it is cheap to obtain a similar service from multiple providers [Vuk10]. The principal BFT approach concentrates on two kinds of services: Storage: The service implements a shared memory, which emulates common data storage device to one or more clients. The model is inspired by accessing main memory in a shared-memory multiprocessor system. Cloud data storage provides related forms of storage to clients. State machines: A state machine consists of variables representing state and commands that update these variables. Commands are deterministic programs that may also produce output. The outputs of such a state machine are determined by the initial state and the sequence of commands previously executed. Any service implemented by the state machine can be made fault-tolerant by replicating it on different processes, and by ensuring that all replicas deliver the commands from different clients in the same order, and hence maintain the same state. The key abstraction to implement this is called total-order broadcast or atomic broadcast; it is non-trivial to implement in asynchronous distributed systems subject to faults (regardless whether the faults are crashes or malicious intrusions). The rest of this section describes simple replicated implementations of (Byzantine-tolerant) distributed storage. More information on both approaches is available in the literature [CGR10]. 4.1 Storage model Motivation. Registers or read/write registers are a simple and useful abstraction for shared data storage. In the so-called shared-memory model, processes access concurrent data objects asynchronously. Wait-free implementations of such objects guarantee that any process can complete any operation in a finite number of steps, regardless of the execution speeds of the other processes. Registers may be used for communication and process synchronization, but because of their limited operations, objects with richer and more powerful operations have also been considered, like (binary) test-and-set operations or (multi-valued) read-modify-write operations [HS08]. In practice, the storage may take the form of shared memory (RAM) in a multiprocessor system, storage devices (disks) connected to clients over a local network, or cloud storage services accessed over the Internet. 7

8 Definitions. Registers were formalized by Lamport [Lam86]. Definition 4 (Register). A register x is characterized by two operations: write(x, v) OK: writes a value v to register x and returns the symbol OK; read(x) v: reads the register x and returns its value v. W.l.o.g. we consider only one register (and we drop the argument x in the interface.) Furthermore, every process executes at any time only one operation. An operation is invoked at some point in time and returns at a later point in time. When a write operation with value v returns OK, we say that it writes v. The sequential specification of a register requires that each read operation returns the value written by the most recent preceding write operation. Definition 5 (Precedence). For two operations o 1 and o 2, we say that o 1 precedes o 2 whenever o 1 returns before o 2 is invoked (they are sequential), and o 1 is concurrent with o 2 when neither operation precedes the other one. Many variations of registers are considered: Domain: Binary and multi-valued; Concurrent access: Single-reader single-writer (abbreviated SRSW), multiple-readers singlewriter (MRSW), and multiple-readers multiple-writers (MRMW); Semantics: Safe, regular, and atomic (see next). Semantics. The most important aspect of a register is its behavior under concurrent access. W.l.o.g. assume there is an initial write operation. Safe: A register is safe when every read not concurrent with a write returns the most recently written value. Reads that are concurrent with at least one write may return any value in the domain. Regular: A register is regular if it is safe and any read concurrent with a write returns either the most recently written value or a concurrently written value. Atomic: A register is atomic whenever the read and write operations are linearizable, which means that there exists an equivalent totally ordered sequential execution of them. In other words, there exists a permutation π of all invocations and responses in the execution such that the sequential specification of every register holds and such that for any two operations o 1 and o 2 where o 1 precedes o 2 in the execution, o 1 also precedes o 2 in π. (For one writer only, a simpler definition is to require that the register is regular and ensures that if an operation r 1 returns a value written by w 1, an operation r 2 returns a value written by w 2, and r 1 precedes r 2, then w 2 does not precede w 1.) 8

9 p write(x) write(y) q read() x (a) p write(x) write(y) q read() x read() y read() x (b) p write(x) write(y) q read() x read() x read() y (c) Figure 1: Three register executions: (a) a non-regular one, (b) a regular but non-atomic one, and (c) an atomic one. 4.2 Distributed storage implementations Here we consider a fault-tolerant distributed implementation of a register by n storage servers P = {P 1,... P n } in an asynchronous network. Some servers may fail by crashing silently. A protocol emulates the shared data object despite the failure of some servers. The data is read and written by clients through sending messages to the servers over an asynchronous network that provides a reliable point-to-point FIFO channel between every client and every server. The servers do not communicate with each other. For tolerating faults, the data of the register is stored collectively by all servers, using replication or erasure coding. We assume that clients do not fail. Wait-free termination here means that a client completes every operation independently from server failures and independently of the speed of other clients. Let Q be a quorum system on P; one usually considers majority quorums, where Q consists of all subsets of P of cardinality greater than n/2. Algorithm 2 tolerates the failure of a set P \ Q of servers for any Q Q. The message complexity of every operation is 2 Q. In order to fully satisfy the specification, the algorithm has to be augmented with unique identifiers attached to every message, such that a client can always attribute a response to the proper request. Theorem 6. Algorithm 2 is a wait-free implementation of a MRSW regular register on P. Proof sketch. The quorum used by the reader has non-empty intersection with the quorum used in the most recent write that precedes the read. If a write exists concurrent with some read, the reader may also return the concurrently written value. Wait-freedom follows because there exists a quorum of correct servers. 9

10 Algorithm 2 Distributed implementation of a MRSW regular register. Implements: MRSW regular register (R); Uses: Reliable point-to-point links; Initialization: The writer is C w ; it stores a timestamp τ, initialized to 0; Every server P i maintains (τ i, v i ), initialized to (0, ); function write(v) // executed by writer C w only τ τ + 1; send message [WRITE, τ, v] to P 1,..., P n ; wait for an [ACK] message from all P i in some quorum Q; return OK; upon receiving message [WRITE, τ, v] from C w do if τ > τ i then (τ i, v i ) (τ, v); send [ACK] to C w ; // server P i function read() // executed by client C j send message [READ] to P 1,..., P n ; wait for [VALUE, τ i, v i ] messages from all P i in some quorum Q Q; let (τ, v) be the received (τ i, v i ) pair with the largest τ i ; return v; upon receiving message [READ] from C j do send [VALUE, τ i, v i ] to C j ; // server P i Algorithm 2 can be modified to emulate an SRSW atomic register (with a single reader only). The reader additionally maintains a timestamp/value pair (τ, v). If the reader receives a VALUE message containing a higher timestamp than τ, it sets (τ, v) to the timestamp/value pair from the message. Finally, the reader outputs v. This emulates an atomic register only for a single reader. When there are multiple clients C 1, C 2,... reading from the register, synchronizing the value/timestamp pair between the readers requires an additional step. The next algorithm is atomic for multiple readers; it synchronizes the reader timestamp by causing clients to write during a read operation (one can show that this is necessary). Theorem 7. Algorithm 3 implements a MRSW atomic register on a quorum system Q. Proof sketch. The only problem is a write operation w concurrent with multiple reads, say, r 1 and r 2. In this case, observe that if r 1 v precedes r 2 or w(v) precedes r 2, then r 2 v because r 1 and w both write to a quorum that intersects with the quorum from which r 2 obtains its value. 10

11 Algorithm 3 Distributed implementation of a MRSW atomic register [ABD95, AW04]. Implements: MRSW atomic register (R); Uses: Reliable point-to-point links; The implementation is the same as Algorithm 2, except for the read operation modified as shown here. function read() // executed by client C j send message [READ] to P 1,..., P n ; wait for [VALUE, τ i, v i ] messages from all P i in some quorum Q Q; let (τ, v) be the received (τ i, v i ) pair with the largest τ i ; send [WRITE, τ, v] to P 1,..., P n ; wait for a message [ACK] from all P i in some quorum Q Q; return v; 4.3 Byzantine faults When the servers may not only crash, but are Byzantine and may behave arbitrarily, the algorithm can be extended by simply having the writer sign the timestamp/value pair with a digital signature scheme. The reader considers only messages that contain a valid signature [MR98]. References [ABC + 07] G. Ateniese, R. Burns, R. Curtmola, J. Herring, L. Kissner, Z. Peterson, and D. Song, Provable data possession at untrusted stores, Proc. 14th ACM Conference on Computer and Communications Security (CCS), 2007, pp [ABD95] [AKK09] [AW04] [CGR10] [GQ88] H. Attiya, A. Bar-Noy, and D. Dolev, Sharing memory robustly in message-passing systems, Journal of the ACM 42 (1995), no. 1, G. Ateniese, S. Kamara, and J. Katz, Proofs of storage from homomorphic identification protocols, Advances in Cryptology: ASIACRYPT 2009 (M. Matsui, ed.), vol. 5912, Springer, 2009, pp H. Attiya and J. Welch, Distributed computing: Fundamentals, simulations and advanced topics, second ed., Wiley, C. Cachin, R. Guerraoui, and L. Rodrigues, Introduction to reliable and secure distributed programming (Second Edition Draft), Springer, L. C. Guillou and J.-J. Quisquater, A practical zero-knowledge protocol fitted to security microprocessor minimizing both transmission and memory, Advances in Cryptology: EUROCRYPT 88 (C. G. Günther, ed.), Lecture Notes in Computer Science, vol. 330, Springer, 1988, pp

12 [HS08] [JK07] M. Herlihy and N. Shavit, The art of multiprocessor programming, Morgan Kaufmann, A. Juels and B. S. Kaliski, PORs: Proofs of retrievability for large files, Proc. 14th ACM Conference on Computer and Communications Security (CCS), 2007, pp [Lam86] L. Lamport, On interprocess communication, Distributed Computing 1 (1986), no. 2, 77 85, [MR98] D. Malkhi and M. K. Reiter, Byzantine quorum systems, Distributed Computing 11 (1998), no. 4, [Sho99] [SW08] V. Shoup, On the security of a practical identification scheme, Journal of Cryptology 12 (1999), no. 4, H. Shacham and B. Waters, Compact proofs of retrievability, Advances in Cryptology: ASIACRYPT 2008 (J. Pieprzyk, ed.), vol. 5350, Springer, 2008, pp [Vuk10] M. Vukolić, The Byzantine empire in the intercloud, SIGACT News 41 (2010), no. 3,