Protocols for Secure Cloud Computing

Transcription

1 IBM Research Zurich Christian Cachin 28 September 2010 Protocols for Secure Cloud Computing 2009 IBM Corporation

2 Where is my data?

3 Who runs my computation?

4 IBM Research - Zurich Overview 1.Protecting untrusted storage for a single client 2.Consistency and integrity of storage for multiple clients 3.Proofs of storage 4.Intrusion-tolerance via replication Source If Applicable 4

5 1 Protecting untrusted storage for a single client 5

6 Integrity Protection for Remote Storage App A Trusted Storage consists of n data items x 1,..., x n (entries in list, blocks of file...) Applications access storage via integrity checker Checker uses small trusted memory to store short reference value v (i.e., together with encryption key in meta-data) Integrity checker operations Read item and verify w.r.t. v Write item and update v accordingly

7 Implementing an Integrity Checker Use hash function H to compute v? v = H(x 1... x n ) Infeasible for long files No random access to item Use a secret key with a MAC? Suffers from replay attacks Well-known solution: Hash tree [Merkle 79] Overhead of read/verify and write/update is logarithmic (in n) Recent alternatives Dynamic accumulators [CL02] Overhead of read/verify is constant Incremental hashing [BM97,CDDGS03] Overhead of write/update is constant

8 Hash trees for Integrity Checking [Merkle 79] root H 0 H 1 H 00 H 01 H 10 H 11 Parent node is hash of its children Root hash value commits all data blocks Root hash in trusted memory Tree is on extra untrusted storage x 1 x 2 x 3 x 4 To verify x i, recompute path from x i to root with sibling nodes and compare to trusted root hash Read & write operations need work O(log n) Hash operations Extra storage accesses To update x i, recompute new root hash and nodes along path from x i to root

9 Dynamic Accumulator for Integrity Checking An accumulator is a cryptographic abstraction for collecting data values and checking their presence: Init() (a, k) -- generates authenticator/accumulator value a and key k Add(a, i, x i, k) a' -- adds x i to accumulator at position i Update(a, i, x i, k) a' -- updates accumulator at position i to x i Witness(a, i, x i, k) w -- produces a witness w for presence of x i Verify(a, i, x i, w) yes / no -- checks if witness w is valid and proves that entry x i was added to accumulator at position i Without k, it must be infeasible to forge i', x', w' that verify for given a Impl. with public-key crypto under strong RSA assumption [CL02]: Given an RSA modulus N = P Q (with P, Q safe primes), and r Z N, it is infeasible to find a, b s.t. ab = r mod N Accumulator a containing x 1,..., x n is a = r H(1 x1) H(n xn) mod N Witness for x i in a is w = a 1/H(i xi) mod N Verify that x i is contained in a by checking w H(i xi) = a mod N?

10 Incremental Hashing for Integrity Checking Hash function IH(x 1,..., x n ) on n entries x 1,..., x n that allows updates: Given h = IH(x 1,..., x i,..., x n ) and values x i and x' i, one can compute h' = IH(x 1,..., x' i,..., x n ) in time independent of n. Implementation based on number theory [BM97]: IH(x 1,..., x n ) = H(1 x n ) H(n x n ) mod p for large prime p and ordinary hash function H( )

11 2 Consistency and integrity of storage for multiple clients 11

12 Model Client Client Client Clients: C 1... C n Correct, but may crash Invoke operations on server Do not talk to each other Small trusted memory Server S Normally correct Sometimes faulty (untrusted, Byzantine)

13 Using an [untrusted] service Clients interact with service through operations (request/reply) Clients may digitally sign their requests Server cannot forge reply values But answer with outdated values ("replay attack") But send different values to different clients

14 The problem C 1 C 3 C 1 write(1,x) write(1,u) write(1,t) C 2 write(2,v) read(1) x write(2,w) C 3 read(1) u read(2) w

15 Goals No forged replies But server may cause inconsistency Clients should see only consistent history No inconsistent operation visible Out-of-band communication for detecting server misbehavior When server correct (normal case), clients want strong consistency and strong liveness Linearizability Wait-freedom (cannot always be achieved)

16 Fork-linearizability [MS02, LKMS04, CSS07] C 1 write(1,x) write(1,u) write(1,t) C 2 write(2,v) read(1) x write(2,w) C 3 read(1) u read(2) w w(1,x) w(2,v) w(1,u) r(1) u r(1) xw(2,w) w(1,t) View of C 1 r(2) w View of C 3 View of C 2

17 Fork-linearizability formally A history is fork-linearizable i exists subset i and permutation i of i s.t. All operations of C i are in i ; i is sequential and follows specification; If o i j, then i = j up to o; i preserves real-time order of i.

18 Inefficient protocols Trivial method: Sign the complete history Server sends history with all signatures Client verifies all operations and signatures Client adds its operation and signs new history Message size proportional to system age Use n version vectors [MS02] Communication complexity O(n2) Message size 400MB for 10'000 users

19 More efficient protocol (linear complexity) [CSS07] Client C i stores a version v i Increment at every operation Vector of versions orders operations After every operation, client signs new value and new vector V = v1 v2 v3 Client stores version vector T of last operation Version V of next operation must be V T Signatures must verify

20 Illustration C 2 T = σ t1 t2 t3 [SUBMIT, read, 1] V = v1 v2 v3 X = x1 x2 x3 V T? v2 = t2? verify σ? If not abort. T := V σ' := sign(t) [REPLY, V, σ, x1] [COMMIT, read, T, σ'] V := T σ := σ'

21 Discussion If clients are forked, their versions become incomparable u v w+1? u v+1 w Signatures prevent server from other manipulations O(n)-protocol for emulating fork-linearizable shared memory on Byzantine server Message size 40KB for 10'000 users Increasing concurrency? Here, clients proceed in lock-step mode Extensions of this protocol let all clients operate concurrently

22 Properties of fork-linearizable storage protocol If server correct, then linearizable Correct server schedules ops. in order of arrival If server Byzantine, then admits only fork-linearizable client views From properties of versions Requires waiting Improved versions of this protocol do not require waiting Complexity Three messages Message size O(n), with n clients

23 3 Proofs of storage 23

24 4 Intrusion-tolerance via replication 24

25 Further reading Introduction to Reliable and Secure Distributed Programming C. Cachin, R. Guerraoui, L. Rodrigues 2nd ed. of Introduction to Reliable Distributed Programming To be published by Springer, 2010 More info on 25

26 References (1) [BM97] M. Bellare and D. Micciancio. A new paradigm for collision-free hashing: Incrementality at reduced cost. In Advances in Cryptology: EUROCRYPT '97, vol of Lecture Notes in Computer Science, Springer, [CDDGS03] D. Clarke, S. Devadas, M. van Dijk, B. Gassend, and G. E. Suh. Incremental multiset hash functions and their application to memory integrity checking. In Advances in Cryptology: ASIACRYPT 2003, vol of Lecture Notes in Computer Science, Springer, [CL02] J. Camenisch and A. Lysyanskaya. Dynamic accumulators and application to efficient revocation of anonymous credentials. In Advances in Cryptology: CRYPTO 2002, vol of Lecture Notes in Computer Science, Springer, [CSS07] C. Cachin, A. Shelat, and A. Shraer. Efficient fork-linearizable access to untrusted shared memory. In Proc. 26th ACM Symp. Principles of Distributed Computing (PODC), [KRS+03] M. Kallahalla, E. Riedel, R. Swaminathan, Q. Wang, and K. Fu. Plutus: Scalable secure file sharing on untrusted storage. In Proc. 2nd USENIX Conference on File and Storage Technologies (FAST 2003), 2003.

27 References (2) [LKMS04] J. Li, M. Krohn, D. Mazières, and D. Shasha. Secure untrusted data repository (SUNDR). In Proc. Symp. Operating Systems Design and Implementation (OSDI), [MS02] D. Mazières and D. Shasha. Building secure file systems out of Byzantine storage. In Proc. 21st ACM Symp. Principles of Distributed Computing (PODC), [PC07] R. Pletka and C. Cachin. Cryptographic security for a high-performance distributed file system. In Proc. 24th Mass Storage Systems and Technologies (MSST), Sept