Lecture I: Data Storage Security in Cloud Compu7ng

Transcription

1 Lecture I: Data Storage Security in Cloud Compu7ng Kui Ren Associate Professor Department of Computer Science and Engineering University at Buffalo

2 Disclaimer! The lecture slides are partially collected from the Internet for the educational purpose only. The lecturer does not claim any credit for them and the copyrights belong to the original authors.

3 Outline Introduc7on to Cloud Compu7ng Cloud Data Storage and Security Challenges Our Research Efforts Further Discussion on the Subject 3

4 Cloud Compu7ng: the Big Thing 4

5 Cloud Compu7ng: the Big Thing Tremendous momentum: Predic'on on Federal IT spendable to move to the cloud from US CIO.Gov in Feb Predic'on on cloud compu'ng revenue in 2012 from Market- research firm IDC. 5

6 Cloud Compu7ng: the Big Thing Tremendous momentum: The overall cloud market will hit $71 billion in 2015 Source: Gartner Company data, Macquarie Capital (USA), Jan Cloud providers bring in $2B in first quarter - - source: Synergy Research Group, May,

7 Cloud Compu7ng: Advantages Cloud compu7ng enjoys a "pay- per- use model for enabling available, convenient and on- demand network access to a shared pool of configurable compu7ng resources (e.g., networks, servers, storage, applica7ons and services) that can be rapidly provisioned and released with minimal management effort or service provider interac7on. NIST 7

8 Cloud Service Stacks So]ware as a service Pla\orm as a service Infrastructure as a service 8

9 Cloud Deployment Models Public Private 9

10 Challenges for Cloud Compu7ng 10

11 Cloud Raises Big Security Challenges! Data Loss and Leakage Insider a_acks 11

12 Cloud Raises Big Security Challenges! Service Vulnerability Denial of Service Service Abuse 12

13 Broad A_acking Surface for Public Cloud Data flow Data flow Data owners Data owners Loss of physical control Tradi7onal adversaries: Hackers, malwares, etc. As well as: Cross- VM a_acks from mul7- tenants; Leaking Personal Iden7fiable Informa7on from rogue employees ; Even providers who control the en7re infrastructure Many others yet to be iden7fied Virtualized server Main concerns: will my data be safe? will anyone see it? can anyone modify it? what if I don t trust the cloud operator? App OS App1 OS Hypervisor Hardware App2 13 App OS

14 Security Challenges in Cloud Storage Outsourcing vs. Storage Security Cloud Data Encryp7on vs. Data U7liza7on Storage Outsourcing vs. Access Control Computa7on Outsourcing vs. Data Security U7lity Compu7ng vs. Trustworthy Metering & Pricing Resource Virtualiza7on vs. Virtualiza7on Security Security Overhead vs. Cloud Benefits and many more 14

15 Outline Introduc7on to Cloud Compu7ng Cloud Data Storage and Security Challenges Our Research Efforts and Proposed Designs Further Discussion on the Subject 15

16 Storage Outsourcing vs. Storage Security Data flow Data flow Data owners Data owners Loss of physical control Cloud storage service allows owners to outsource their data to cloud servers for storage and maintenance. Low capital costs on hardware and so]ware, low management and maintenance overheads, universal on- demand data access, etc E.g., Amazon S3. However, data outsourcing also eliminates owners ul7mate control over their data. 16

17 Storage Outsourcing vs. Storage Security Cloud currently offers no guarantee: Amazon S3: not liable to any data damages or data loss. Broad range of threats for data integrity do exist: Internal: Byzan7ne failure, management errors, so]ware bugs, etc. External: malicious malware, economically mo7vated a_acks, etc. E.g., Amazon S3 - Feb., Jul. 2008; Gmail - Dec. 2006, Mar. 2011; Apple MobileMe - Jul. 2008, Hotmail Dec. 2010, Cloud servers might behave unfaithfully: Discard rarely accessed data for monetary reason Hide data loss incidents for reputa7on Data owners demands con7nuous storage correctness assurance for their data in the cloud. 17

18 Need to Create Security Visibility inside Cloud Is my data correctly stored? Storage correctness proofs Proac7ve storage audi7ng mechanism to ensure con7nuous correctness of outsourced cloud data. To help extend data trust perimeter into the cloud. To meet security, system, and performance requirements. 18

19 Secure Cloud Storage Audi7ng Demand efficient storage correctness guarantee without requiring local data copies. Tradi7onal methods for storage security can not be directly adopted. Retrieving massive data for checking is unprac7cal. (large bandwidth) Allow meaningful tradeoffs between security and overhead. Communica7on and computa7on costs should be low. audi7ng cost should not outweigh its benefits. Cope with frequent cloud data changing while ensuring con7nuous data audi7ng. Cloud data may be frequently updated by owner for applica7on purposes Audi7ng mechanisms inherently need to support data dynamics. 19

20 Secure Cloud Storage Audi7ng (Cont d) Enable public audi7ng for unified risk evalua7on. Introduce a third- party auditor saves owners compu7ng resources and simplifies the audi7ng management at cloud. Public audi7ng should not affect owner s data privacy. Handle mul7ple audi7ng tasks simultaneously (batch audi7ng) The individual audi7ng of each data file can be tedious and inefficient. Batch audi7ng improves efficiency and saves computa7on overhead. 20

21 Outline Cloud Compu7ng Background Cloud Data Storage and Security Challenges Our Research Efforts and Proposed Designs Storage audi7ng with data dynamics support Privacy- preserving public audi7ng Efficiency improvement via batch audi7ng Further Discussion on the Subject 21

22 Outline Cloud Compu7ng Background Cloud Data Storage and Security Challenges Our Research Efforts and Proposed Designs Storage audi7ng with data dynamics support Privacy- preserving public audi7ng Efficiency improvement via batch audi7ng Further Discussion on the Subject 22

23 Dynamic Storage Audi7ng Cloud hosts not only sta-c but dynamic data Data flow Security message flow Outsourced data can be frequently changing due to updates. Outsourced file storage, databases, data, log files, etc. How to design efficient storage audi7ng mechanism with inherent support of data dynamics? The most general forms of data update include data block modifica7on, inser7on, and dele7on.

24 The tradi7onal approach is not applicable. Owner pre- computes MACs for the data. Owner Straigh\orward Approaches Cloud Server MAC K1 (Data) reveal K 1 Data* MAC K2 (Data) MAC K3 (Data) Keys may be used up! MAC K1 (Data*) No data dynamics support! Cloud processes entire data online per audit! equal?" 24

25 Straigh\orward Approaches The random- sampling approach Check only a small por7on of the data per audit Achieve probabilis7c integrity guarantee via random sampling Owner pre-computes an authenticator (e.g., signature/mac) for each data block. m 1 σ 1 m 2 σ 2 m 3 σ 3 m 4 σ 4 m n σ n Owner randomly sample block/authenticator pairs m 1 σ 1 m 2 σ 2 m 4 σ 4 Cloud Server 1. Linear bandwidth cost w.r.t. sample size; 2. Linear computational cost - need to verify each block/authenticator pair. 25

26 Construct Homomorphic Authen7cator Homomorphic authen7cator provides integrity authen7ca7on and has the aggrega7on property. BLS signature based instan7a7on: x, g x is private/public key pair, H(.) : hash to point func7on, u, g are generators for group G., Data block: Authen7cator: Verifica7on: Homomorphic: aggrega7on of authen7cators and data blocks μ + σ m 1 σ 1 m i. σ i m 2 σ 2 26

27 Construct Homomorphic Authen7cator Audit the aggregated block and authen7cator for the constant bandwidth cost and much saved computa7onal cost. Owner randomly sample block/authenticator pairs m 1 σ 1 m 1 σ 1 m 2 σ 2 m 2 σ 2 m 3 σ 3 m 4 σ 4 m 4 σ 4 μ σ m n σ n Cloud Server verify μ and σ once only small and constant bandwidth Homomorphic property allows blocks and authenticators to be combined into single value Not designed to support data dynamics! 27

28 Analysis of Exis7ng Work G. Ateniese et al. 07 RSA based H. Shacham et al. 08 BLS signature based v, name: randomly chosen labels for data names; d, x: related private keys; H(.), h(.) : hash to point functions. m 1 m 2 m 3. m n σ 1 σ 2 σ 3. σ n Direct extension to data dynamics is insecure. E.g., block modifica7on from m i to m i + Δm allows adversary to obtain Δm and by dividing newly computed σ i and original σ i Adversary could now maliciously modify any block m s to m s * = m s + Δm and forge legi7mate authen7cator σ s * as: New authen7cator construc7on is required to avoid the a_ack. 28

29 Analysis of Exis7ng Work G. Ateniese et al. 07 RSA based H. Shacham et al. 08 BLS signature based m 1 m 2 m 3. m n σ 1 σ 2 σ 3. σ n A secure authen7cator must enforce the block index, i.e., posi7on/ sequence informa7on. Prevent adversary from using authen7cators to obtain proofs for different blocks. E.g., use any valid (m s,σ s ) pair to pass challenges for corrupted m t successfully. But keeping index informa7on makes data updates highly inefficient. E. g., inser7ng a block at any posi7on will require retrieving all the subsequent data blocks and re- computa7on of all corresponding authen7cators. Can we eliminate the index informa7on but s7ll enforce block posi7on without affec7ng the security? " 29

30 Our Design Overview Construct a new authen7cator using H(m i ) instead of H(name i). New authen7cator supports secure block modifica7on opera7on. H(m i ) changes for every block updates, so the aforemen7oned a_ack on block modifica7on is no longer valid. O Elimina7on of index for efficient block inser7on/dele7on opera7on. We are yet to have a way to enforce the block index sequence. 30

31 Our Design Overview Construct a novel sequence- enforced Merkle Hash Tree (smht). Rank of each tree node: the # of leaves that can be reached from the node. R = h(h A h B 4) h A = h(h 1 h 2 2) h 1 = h(x 1 1) h 1,1 It s also the sum of its children s ranks. A h A,2 Root= (R,4) B h B,2 C D E F h 2,1 h 3,1 h 4,1 x 1 x 2 x 3 x 4 Sequence of the ordered set of leaves Lv:2 Lv:1 Lv:0 Auxiliary Authen7ca7on Informa7on (AAI) To verify x 3 s value and posi7on, we use root (R,4) and AAI = {(h 4,1,0), (h A,2,1)}: 1. Compute rank of B as 1+1 = 2 and h B = h(h(x 3 1) h 4 2); 2. Compute rank of root as 2+2 = 4 and R = h(h A h B 4); 3. Verify if R = R and also if LEFT(x 3 ) = 2. Construct smht with an ordered set {H(m i )} i=1,,n as the leaf nodes, and use root (R,n) to ensure correct block posi7on informa7on: x i = H(m i ), i = 1,, n 31

32 The Protocol Illustra7on Prepara7on: Owner generates smht, keeps root (R, n), and outsources {Data, σ i s, smht} to the cloud. Audi7ng: Owner challenges cloud on randomly selected data blocks. Cloud responds with the corresponding {μ, σ, Ω}. Owner data outsource m 1 σ 1 Cloud Server m 2 σ 2 m 3 σ 3 m 4 σ 4 m 8 σ 8 σ i {v 1, v 5, v 6, v 8 } random positions & coefficients µ = v 1 m 1 +v 5 m 5 +v 6 m 6 +v 8 m 8 Owner verifies µ and σ with Ω! and Ω 32

33 The Protocol Illustra7on: Audi7ng Step 1: Owner uses root (R,8) and Ω to authen7cate the posi7ons of {H(m i )} i=1,5,6,8 and hence those of {m i } i=1,5,6,8. AAI Root R,8 check if R = h(h A h B 8) and if LEFT(x i )=i-1, for i=1,5,6,8 h A = h(h C h D 4) h A, 4 A B h B, 4 h B = h(h E h F 4) h C = h(h 1 h 2 2) C D E F h C,2 h D,2 h E,2 h F,2 h E = h(h 5 h 6 2) h F = h(h 7 h 8 2) h 1 = h(x 1 1) h 1,1 h 2,1 h 3,1 h 4,1 h 5,1 h 6,1 h 7,1 h 8,1 h 8 = h(x 8 1) h 6 = h(x 6 1) h 5 = h(x 5 1) x 1 x 2 x 3 x 4 x 5 x 6 x 7 x 8 x i = H(m i ), i=1,...,8 Ω = {H(m i )} i=1,5,6,8,and the corresponding AAI from smht 33

34 The Protocol Illustra7on: Audi7ng Step 2: With {H(m i )} i=1,5,6,8 authen7cated, owner further checks Random coefficients chosen by owner Public key Audi7ng materials from cloud 34

35 The Protocol Illustra7on: Support Data Dynamics Support general block- level opera7ons: Modifica7on (M), dele7on (D), and inser7on (I) One step closer towards prac7cal audi7ng mechanisms Update opera7on: the block, its corresponding authen7cator, and the smht When inser7ng/dele7ng a block, authen7cators for all other blocks remains the same, i.e., no authen7cator re- computa7on or data retrieving is necessary. Owner- side Updates: Ω, h(h(m*)) 35

36 Support Data Dynamics: Block Inser7on Owner 1. Compute σ* for new block m*. Root (R,4) A h A,2 h B,2 B {m*, σ*} Insert m* after m 2 Insert h(x* 1),1 after h 2,1 Cloud Server 2. Insert m* and update smht. Root (R*,5) A B h A *,3 h B,2 C h 1,1 h c,2 h 3,1 h 4,1 h 1,1 h 2,1 h 3,1 h 4,1 x i = H(m i ) h i =h(x i 1) h 2,1 h(x* 1),1 n 3 Ω ={(h 1,1,0), (h 2,1,0), (h B,2,1)} 3. Authen7cate received Ω with local (R,4). 4. Compute (R*,5) with Ω and local h(h(m*) 1)= h(x* 1). 36

37 Remarks In our scheme, we store addi7onal meta data in the tree structure to assist authen7ca7on. E.g., store addi7onal rank informa7on of the tree at the server. It helps eliminate the need for the owner to keep track of the tree structure, while keeping our design secure. Otherwise, the owner will have to record local state informa7on for each update he conducts - Quite a burden from prac7cal point of view. 37

38 Example: Storing Rank of Nodes Rank of node i denotes the number of leaf nodes that belong to this sub- tree with node i as the root. Root = h(h A h B 1000); Root,1000 h B = h(h C h D 600); h C = h(h E h F 400); h F = h(h(m 750 ) 1); h A, h E, h C, 400 h B, 600 h D, h F,1 Leaf node: H(m 750 ) x i = H(m i ), i=1,...,n The owner can directly use authen7cated rank values to verify that the node F is indeed the 750- th node.

39 Efficiency Enhancement Using MHT, persistent inser7on on the same posi7on would result in worst case complexity to be O(n). Since the tree height keeps increasing. But other more- balanced tree structures can be directly u7lized to replace the MHT and maintain worst case performance to be O(log n). E.g., Skiplist, B+ tree can be used. Homework: you can check these details by reading the corresponding papers.

40 Security Analysis Our proposed authen7cator construc7on can be proved to be existen7ally unforgeable. Use the fact that the BLS signature is existen7ally unforgeable. By contradic7on: if an adversary can forge our authen7cator scheme à we can use the adversary to forge a BLS signature. Simulator Adversary Forge A forged BLS signature passes the verification Contradiction! 40

41 Security Analysis (cont d) The soundness of our storage correctness guarantee is based on the hardness of Computa7onal Diffie- Hellman (CDH) problem. CDH: Given g, g α, h G for unknown α Z p, to output h α. By contradic7on: If an adversary can respond corrupted to pass the verifica7on à we can solve the CDH problem Simulator CDH is solved à Contradiction! 41

42 Probabilis7c Guarantee of Random Sampling Assume r out of n blocks are corrupted, how many blocks should we randomly sample to detect it with high probability? Let X denote the number of corrupted blocks picked by the random- sampling. Then sampling c blocks gives detec7on probability P =1 P {X =0} =1 cy 1 (1 min{ r n i, 1}) i=0 1 ( n r n )c =1 (1 t) c, where t = r n If t = 1% of file is corrupted, randomly sample a constant of c = 460 blocks to maintain detec7on probability P = Error- correc7ng code can be used to correct small data errors. 42

43 Performance Evalua7on Table 1: Comparisons with the- state- of- art. Ateniese et al. CCS'07 Shacham et al. ASIACRYPT'08 Ateniese et al. SecureComm'08 Our TPDS 11/ ESORICS 09 Data dynamics No Par7ally + Yes Sever comp. complexity O(1) O(1) O(1) O(log n) Owner comp. complexity O(1) O(1) O(1) O(log n) Comm. Complexity O(1) O(1) O(1) O(log n) Owner storage complexity O(1) O(1) O(1) O(1) +: The scheme only supports bounded number of integrity challenges and par7ally data updates, i.e., data inser7on is not supported. 43

44 Performance Evalua7on (cont d) Table 2: performance comparisons with different instan7a7ons. System Parameters Performance Results Our BLS based instan7a7on Our RSA based instan7a7on Data corrup7on rate t 1% 3% 1% 3% Detec7on probability P Randomly sampled blocks c Server comp. 7me (ms) Owner comp. 7me (ms) Comm. cost (KB) Our experiment is conducted using C on a system with a processor running at 2.4 GHz, 768 MB of RAM. The performance is measured for 1 GB data under data corrup7on rate t = 1% and 3% while maintaining detec7on probability P = 0.99, where P 1 - (1 t ) c and c is the sample size. The block size of RSA- based instan7a7on is chosen to be 4 KB. Note that error- correc7ng code can be used to correct small data errors (e.g., t < 1%). 44

45 Short Summary We explore the problem of cloud storage audi7ng with data dynamics support. We carefully designed a new homomorphic authen7cator and achieve the goal with a novel sequence- enforced Merkle Hash Tree (smht) design. We conduct experiments for both BLS- based and RSA- based instan7a7ons. Extensive security and performance analysis shows that the proposed scheme is provably secure and highly efficient. 45

46 Outline Cloud Compu7ng Background Cloud Data Storage and Security Challenges Our Research Efforts and Proposed Designs Storage audi7ng with data dynamics support Privacy- preserving public audi7ng Efficiency improvement via batch audi7ng Further Discussion on the Subject 46

47 Public Audi7ng with Third- party Auditor Resource constrained Data flow Security message flow Large amount of data Maintaining storage correctness guarantee demands con7nuous audi7ng. High computa7on/communica7on costs and online burdens for data owners. Introduce a third- party auditor (TPA) for correctness evalua7on Owners can be worry- free by resor7ng to TPA for audi7ng tasks. 47

48 Public Audi7ng VS. Data Privacy Third- party auditor Data flow TPA should not learn the content of the data, when performing audi7ng on behalf of data owners. Unauthorized informa7on leakage is unwanted by data owners Legal regula7ons, e.g., HIPAA, may mandate it. Privacy- preserving public audi7ng mechanism is desired.

49 Revisit Exis7ng Approaches σ i Owner Data outsource m 1 σ 1 m 2 σ 2 Cloud Server m 3 σ 3 m 4 σ 4 m n σ n TPA with g x {v 1, v 5, v 6, v 8 } random positions & coefficients μ = v 1 m 1 +v 5 m 5 +v 6 m 6 +v 8 m 8 μ = v 1 m 1 +v 5 m 5 +v 6 m 6 +v 8 m 8 leaks the data to TPA. Direct adop7on is unsuitable for public audi7ng. Can recover all m i s by solving the linear equa7on systems. Assuming data encryp7on before outsourcing? NOT sa7sfying. Method not self- contained; Leave the problem to key management An overkill for certain types of data, e.g., libraries, scien7fic data, 49

50 Privacy- preserving Public Audi7ng Achieve privacy- preserving audi7ng regardless of data encryp7on. Construct homomorphic aggrega7on with random masking. TPA {v 1, v 5, v 6, v 8 } random positions & coefficients m 1 σ 1 m 2 σ 2 Cloud Server m 3 σ 3 m 4 σ 4 m n σ n verify μ and σ μ = v 1 m 1 +v 5 m 5 +v 6 m 6 +v 8 m 8 With randomly masked μ, owner s data content is no longer exposed! server combines corresponding blocks and randomly masks it. Random masking must not affect storage correctness validation! 50

51 Privacy- preserving Public Audi7ng System Parameters:,.,, TPA {v 1, v 5, v 6, v 8 } random positions & coefficients m 1 σ 1 m 2 σ 2 Cloud Server m 3 σ 3 m 4 σ 4 m n σ n μ = v 1 m 1 +v 5 m 5 +v 6 m 6 +v 8 m 8 The soundness of our privacy-preserving auditing mechanism can be proved under the random oracle model. µ 1. Cloud server picks a random r. 2. Computes 3. μ = r + γ μ mod p. 51

52 The Correctness Elabora7on µ' : the original block µ : the blinded block 52

53 Remarks on Privacy- preserving Audi7ng We have proved our construc7on of R and γ as γ = h(r) would not affect the security of storage audi7ng equa7on. The scheme works under semi- trusted security model i.e., the colluding between cloud server and TPA not considered The scheme can support data dynamics straigh\orwardly. Elimina7on of block index in authen7cator U7lizing sequence- enforced MHT (smht) Other privacy- preserving audi7ng construc7ons are possible. 53

54 Security Analysis The privacy preserving guarantee is proved in the random oracle model using γ = h(r). We prove the existence of a simulator, who controls the random oracle h(.) and can produce a valid response {R, σ, µ } without the knowledge of µ. Assume the simulator is given a valid σ. 1. Simulator randomly picks γ and µ from Z p. 2. Simulator sets µ 3. Simulator backpatches (or sets) γ = h(r), as it controls the random oracle h(.). Since simulator generates a valid response {R, σ, µ } without knowing µ, it means from response {R, σ, µ }, TPA learns nothing on µ. 54

55 Security Analysis The soundness of our modified audi7ng mechanism is based on the underlying (original) storage audi7ng mechanism. We prove the existence of an extractor who can extract µ from valid {R, σ, µ }. The extractor controls the random oracle h(.) and answers queries issued by cloud server for h(r). 1. Extractor answers γ = h(r) and cloud server outputs valid {λ, σ, µ } such that µ 2. Extractor rewinds (resets) cloud server and returns γ* = h(r) for the query of h(r). Cloud server outputs {R, σ, µ* } such that µ* 3. By dividing the two equa7ons, the extractor can obtain valid {σ, µ}, where µ =( µ* - µ )/ (γ*- γ), for original storage audi7ng equa7on (such as Shacham s scheme). With valid {σ, µ}, the soundness of our audi7ng scheme follows from exis7ng soundness proofs.

56 Cost of Privacy- Preserving Guarantee System parameters Performance results Table 3: performance comparisons with previous work Our INFOCOM 10 Shacham et al. ASIACRYPT'08 Data corrup7on rate - t 1% 1% 1% 1% Detec7on probability - P Randomly sampled blocks - c Server comp. 7me (ms) TPA comp. 7me (ms) Comm. cost (Byte) Privacy- preserving Yes No Our experiment is conducted using C on a system with an Intel Core 2 processor running at 1.86 GHz, 2048 MB of RAM. Our analysis shows that if the server is missing t=1% of the data blocks, the TPA only needs to audit for c=460 or 300 randomly chosen blocks so as to detect this misbehavior with probability P larger than 0.99 or

57 Short Summary Enable public audi7ng is of cri7cal importance for its unified risk evalua7on for cloud storage services. But public audi7ng should not affect owner s data privacy. A public storage audi7ng scheme u7lizing a new random- masking construc7on with homomorphic authen7cators is designed. The design also supports data dynamics straigh\orwardly. Extensive security and performance experiments show the proposed schemes are provably secure and highly efficient. 57

58 Outline Cloud Compu7ng Background Cloud Data Storage and Security Challenges Our Research Efforts and Proposed Designs Storage audi7ng with data dynamics support Privacy- preserving public audi7ng Efficiency improvement via batch audi7ng Further Discussion on the Subject 58

59 Batch Audi7ng TPA may concurrently handle mul7ple audi7ng delega7ons. Individually audi7ng each tasks can be tedious and overall inefficient. We explore the algebraic property of BLS signature and slightly modify the protocol in a single owner case for simultaneous audi7ng. (details skipped) TPA {v 1, v 5, v 6, v 8 } randomly-chosen coefficients m 1 σ 1 m 2 σ 2 Cloud Server m 3 σ 3 m 4 σ 4 m n σ n owner 1 verify µ 1 and σ 1 verify µ 2 and σ 2 verify µ k and σ k m 1 σ 1 m 1 σ 1 m 2 σ 2 m 2 σ 2 m 3 σ 3 m 3 σ 3 m 4 σ 4 m 4 σ 4 m n σ n m n σ n owner 2 owner k Verify µ 1, µ 2,, µ k, and an aggregated σ in a single equation. 59

60 Recap on Bilinear Pairing

61 Batch Audi7ng: Efficiency Enhancement Highlight Aggregate K equa7ons into single one 61

62 Privacy- preserving Batch Audi7ng: Efficiency Enhancement Highlight Aggregate K equa7ons into single one

63 Remarks on Batch Audi7ng Aggrega7ng K (K >= 2) verifica7on equa7on into 1 saves expensive pairing opera7ons from 2K to K+1. A considerable amount of audi7ng 7me can be saved. Correct verifica7on means all checked blocks are valid. Due to the security strength of BLS based authen7cators and verifica7on equa7on. Failed verifica7on means one or more owners data are corrupted. Divide- and- conquer approach (binary search) to find invalid responses. 63

64 Batch Audi7ng Efficiency 520 Auditing time per task (ms) individual auditing batch auditing (c=460) batch auditing (c=300) Number of auditing tasks Batch audi7ng indeed helps reduce the TPA s computa7on cost, as more than 11% and 14% of per- task audi7ng 7me is saved, when c=460 or 300, respec7vely. 64

65 Sor7ng Out Invalid Responses Auditing time per task (ms) individual auditing batch auditing (c=460) batch auditing (c=300) Fraction of invalid responses α Even the number of invalid responses exceeds 15% of the total batch size, the performance of batch audi7ng can s7ll be safely concluded as more preferable than the individual audi7ng.

66 Short Summary Handle mul7ple audi7ng tasks simultaneously (batch audi7ng) is in great need as data are increasingly outsourced to cloud The individual audi7ng of each data file can be tedious and inefficient. Batch audi7ng improves efficiency and saves computa7on overhead. We leverage the algebraic property of BLS signature based homomorphic authen7cators and construct correct and secure batch audi7ng protocols. We demonstrate via experiments that the proposed batch audi7ng schemes outperforms individual audi7ng in terms of per task audi7ng 7me. 66

67 Related Publica7ons Q. Wang, C. Wang, J. Li, Kui Ren, and W. Lou, "Enabling Public Verifiability and Data Dynamics for Storage Security in Cloud Compu7ng", in IEEE Transac-ons on Parallel and Distributed Systems, Vol. 22, No. 5, pp , May, (also appears in Proc. of ESORICS, 2009, AR = 19%) #1 top accessed IEEE TPDS ar7cle in IEEE Xplore as in December 2011 C. Wang, Q. Wang, Kui Ren, and W. Lou, "Privacy- preserving Public Audi7ng for Data Storage Security in Cloud Compu7ng, IEEE Transac-ons on Computers, Vol. 62, No. 2, pp , (also appears in Proc. of IEEE INFOCOM, 2010, AR = 17.5%) #1 top accessed INFOCOM'10 ar7cle in IEEE Xplore as in December 2011 C. Wang, Q. Wang, Kui Ren, and W. Lou, "Ensuring Data Storage Security in Cloud Compu7ng, IEEE Transac-ons on Service Compu-ng, Vol. 5, No. 2, pp , 2012 (also appears in Proc. of IWQoS, 2009) C. Wang, Kui Ren, W. Lou, and J. Li, "Towards Publicly Auditable Secure Cloud Data Storage Services", IEEE Network, vol. 24, no. 4, pp , 2010 #2 top accessed IEEE Network ar7cle in IEEE Xplore as of July 2011 Kui Ren, C. Wang, and Q. Wang, "Security Challenges for the Public Cloud, IEEE Internet Compu-ng, Vol. 16, No. 1, pp , Jan/Feb, 2012 (Invited Paper) 67

68 Outline Cloud Compu7ng Background Cloud Data Storage and Security Challenges Our Research Efforts and Proposed Designs Storage audi7ng with data dynamics support Privacy- preserving public audi7ng Efficiency improvement via batch audi7ng Further Discussion on the Subject 68

69 More Cloud Storage Security Related Topics Proofs of data redundancy Proofs of data encryp7on Assured dele7on Proofs of geoloca7on Proofs of ownership vs. deduplica7on More to be iden7fied 69

70 More Cloud Storage Security Related Topics Proofs of data redundancy Proofs of data encryp7on Assured dele7on Proofs of geoloca7on Proofs of ownership vs. deduplica7on More to be iden7fied 70

71 Proofs of Data Redundancy: Challenges on The physical layer Amazon claims to store three dis7nct copies of my file for resilience. Can they prove it? Audi7ng won t do the trick, nor will downloading! Slides credits to Ari Jules et al. Alice F F F F F F F F or?

72 Virtualiza7on is a complica7on Erasure coding across disks Disk 1 Disk 2 Disk 3 Disk 4 Disk 5 My file can survive two disk crashes!

73 Virtualiza7on is a complica7on Erasure coding across disks Virtual Virtual Virtual Virtual Virtual Disk 1 Disk 2 Disk 3 Disk 4 Disk 5 X A My single file can disk survive crash can two destroy disk crashes! my file!

74 How to Tell if Your Cloud Files Are Vulnerable to Drive Crashes Proofs for that the tenant s files can survive drive crashes

75 Prove Disk- crash Resilience Disk 1 Disk 2 Disk 3 Disk 4 Disk 5 Claim: File can survive two disk crashes! The Challenge: How can a cloud provider prove that certain bits sit on certain disks?

76 Mo7va7on and Idea Cloud server: We store 3 copies of your file in 3 different drives. We are 2 fault- tolerant. Pizza store: We have 2 ovens. How do you know if it s true? Idea : mul7ple devices can do parallel work but single device can t.

77 Example pizza store Assume we know The pizza store has 2 ovens An oven usually takes 5 min to bake a pizza The store is a 15 min drive from here Time needed for 24 pizzas? 1 oven : 5 24=120 min 2 ovens: 60 min Drive 7me: 15 min Task for the pizza store: Send me 24 pizzas in 80 min. Task for the cloud server: Send me a block of the file from each drive in xxxx milliseconds

78 The Pizza Oven Protocol Six pizzas! Eeta Pizza Pi Cheapskate Pizza

79 The Pizza Oven Protocol Six pizzas! X X Eeta Pizza Pi Cheapskate Pizza

80 The Pizza Oven Protocol Eeta Pizza Pi Cheapskate Pizza Cheapskate now claims it can survive an oven failure! How can Eeta Pizza Pi verify without visi7ng???

81 The Pizza Oven Protocol T 0 Six pizzas! T 1 T 1 T 0 = 45 mins? Eeta Pizza Pi Cheapskate Pizza Suppose that: A pizza oven bakes one pizza at a 7me, and takes 10 minutes The Cheapskate truck takes 15 minutes to deliver to Eeta Pizza Pi

82 Protocol Design for Cloud Servers Core part Choose the threshold of 7me limit Challenges Network latency / pizza delivery traffic 7me Drive read 7me / oven baking speed seek 7me, throughput, RPM, buffer Make the queries to disks unpredictable

83 Network latency Ping hosts in Santa Clara and Shanghai from Boston Several strategies to factor variability in network latency Latency 1 Latency 2 if geographically close Abort protocol if response 7me exceeds 110% of the average Reduce network- 7ming variance when limited bandwidth Server applies hash func7on before transmi ng

84 Drive read 7me Task: Server reads a block from each drive The block size (the size of each g i )? The 7me limit for this task? Two main factors of drive read 7me Seek : disk head moves to the right track and sector Data transfer rate (throughput) The drive used in this paper 3.5ms seek 7me and 73MB/s to 125MB/s throughput

85 Drive determine the block size Seek 7me depends on the distance that the disk head needs to move Throughput depends on the posi7on of the block Outer tracks are faster than inner tracks Sequen7al data are faster than sca_ered data Force to perform a seek for EVERY block Using small block size Query random pa_ern of blocks

86 Drive determine 7me limit Recall the two examples Pizza store with 2 ovens: query 24 pizzas (12 steps) Cloud server with 3 drives: query 3 blocks (1 step) Why use 12 steps instead of 1 step for pizza store? Enlarge the gap between one oven and two ovens How to play the same trick to Cloud server, query q steps (query cq blocks) Solu7on : lock- step à make the queries to disks unpredictable

87 Lockstep Idea Specify query Q in an ini7al step consis7ng of c random challenge blocks, one per drive For each subsequent step, the set of c challenge blocks depends on the content of the file blocks accessed in the last step. The server can proceed to the next step only a]er fully comple7ng the last one.

88 Gap, number of steps, 7me limit Lock- step ensures the security via the increase of the steps The more steps, the larger gap threshold

89 Experiments : c = 5 drives Response 7me gap between honest max and adversary min

90 More Cloud Storage Security Related Topics Proofs of data redundancy Proofs of data encryp7on Assured dele7on Proofs of geoloca7on Proofs of ownership vs. deduplica7on More to be iden7fied 90

91 Proofs of Data Encryp7on: Mo7va7on Slides credit to Stefanov et al. Public cloud has large a_ack surface Thousands of computers Dozens of storage systems and interfaces Amazon alone: S3, EBS, Instance Storage, Glacier, Storage Gateway, CloudFront, RDS, DynamoDB, Elas7Cache, CloudSearch, SQS Shared resources among thousands of tenants Many possibili'es for accidental data leakage. Data encryp'on is a must. 91

92 Defending Against Accidental Data Leakage??? leakage Simple view: Just encrypt your data in the cloud. Problem solved?

93 Defending Against Accidental Data Leakage??? leakage More realis7c view: O]en want to use the cloud for more than just raw storage. Why? Want to outsource storage AND computa'on (services). In that case, the cloud needs access to your decrypted data.

94 Encrypt at Rest & Decrypt on the Fly??? leakage Services Front End Storage Back End Split the cloud into computa7on front- end and storage back- end Already the case in many clouds (e.g., Amazon, Azure) Storage backend only sees encrypted data. Computa7on front- end decrypts data on the fly Only accesses the data it really needs at any one 7me Can be combined with 7ght access control and logging. Key servers

95 Encrypt at Rest & Decrypt on the Fly??? leakage Services Front End Storage Back End J complies with government regula'ons Protects against data leakage by the storage back- end infrastructure. Limits the amount of data leakage by the front- end at any one 7me. Common prac7ce. Much be_er than no encryp7on.

96 Lack of visibility The Problem How can we be reasonably sure that the cloud is encryp'ng data at rest? Plaintext is simpler for the cloud to manage. Users only see results (e.g., web pages) from the front- end. What is happening internally? Download data and check encryp7on? The cloud can always just encrypt on the fly. Seems impossible!

97 One Proposed Solu7on Economically mo'vate the cloud to encrypt data at rest. Impose financial penal'es on misbehaving cloud providers. We ensure that an economically ra'onal cloud provider, encrypts data at rest. Misbehaving cloud must use double storage. Must store both decrypted and encrypted file.

98 One Solu7on: Hourglass Schemes encryp7on hourglass Original File Encrypted File Encapsulated File client uploads file client verifies encryp7on client assists client verifies by periodically challenging random file blocks The client never needs to permanently store and manage keys.

99 Intui7on encryp7on hourglass Original File Encrypted File Encapsulated File adversarial cloud wants to only store Hourglass property: costly to compute on the fly client checks So an adversarial cloud must store both files. Double the storage!

100 Hourglass Framework: More than a Scheme Modular Components Encodings: Encryp7on Watermarking File Bindings Hourglass func7ons: Bu_erfly Permuta7on RSA

101 Encodings Encryp'on: G=E(F) Watermarking: G=F Tag Embed a tag into the file Tag says that the file is stored on a specific cloud Tag signed by the cloud Evidence of data leakage origin. File Binding: G= F 1 F 2 F m Combine mul7ple files into one encoding. E.g., embedded license.

102 Hourglass Func7ons Costly to apply on the fly Impose a resource lower bound on the cloud to compute: Gà H, and hence Fà H F G H encoding (e.g., encryption) hourglass Original File Encrypted File Encapsulated File

103 Hourglass Func7on: RSA F: G: H: F 1 F 2 F 3 F 4 F n G 1 G 2 G 3 G 4 G n H 1 H 2 H 3 H 4 H n Apply encoding (encryp7on, watermarking, file binding) Client computes H i = RSA- Sign(G i ) using random RSA private key. Cloud can always recover the plaintext : G i = RSA- recovermessage(h i ) (using client s public RSA key) F i = Decode(G i ) Resource bound: computa'on Completely infeasible for cloud: Fà H It doesn t have the RSA signing key to do: Gà H

104 Hourglass Func7on: Permuta7on F: G: H: F 1 F 2 F 3 F 4 F n G 1 G 2 G 3 G 4 G n H 1 H 2 H 3 H 4 H n Apply encoding (encryp7on, watermarking, file binding) Randomly permute the blocks of to form. No cryptographic opera7ons. Operates on 7ny blocks. Client later challenges the cloud for sequen7al ranges of H. Sequen'al range in H à Random blocks in F Resource bound: disk seeks A misbehaving cloud (that only stores F) will need to do many random accesses to respond to a challenge.

105 Hourglass Func7on: Bu_erfly w = a known key PRP over a pair of file blocks G 1 G 2 G 3 G 4 G 5 G 6 G 7 G 8

106 Comparison of Hourglass Func7ons RSA exponen'a'ons AES opera'ons random memory accesses less prac'cal more prac'cal RSA Buderfly Permuta'on less assump'ons more assump'ons RSA assump'ons storage speed seek inefficiency in rota'onal drives

107 Comparison of Hourglass Func7ons Ran on Amazon EC2 (using a quadruple- extra- large high- memory instance and EBS Storage).

108 H: Challenge- Response Protocol H 1 H 2 H 3 H 4 H n The client challenges the cloud for blocks of the encapsulated file H. At random unpredictable 7mes Few challenges, e.g., O(log n) Cloud must respond quickly. Doable by an external auditor. Auditor doesn t see the plaintext F.

109 Limita7ons Assume files are not accessed to o]en. Great for archiving files. File updates are costly. RSA hourglass func7on allows for updates. Other hourglass func7ons must be re- applied to the en7re file. Works mainly for large files.

110 More Cloud Storage Security Related Topics Proofs of data redundancy Proofs of data encryp7on Assured dele7on Proofs of geoloca7on Proofs of ownership vs. deduplica7on More to be iden7fied 110

111 Assured Data Dele7on: Mo7va7on A]er outsourcing, can we reliably remove data from cloud? We don t want backups to exist a]er pre- defined 7me e.g., to avoid future exposure due to data breach or error management of operators If an employee quits, we want to remove his/her data e.g., to avoid legal liability Cloud makes backup copies. We don t know if all backup copies are reliably removed. We need assured dele'on: Data becomes inaccessible upon requests of dele7on 111 Slides credit to Patrick Lee et al.

112 One Solu7on: FADE (securecomm 10) FADE: an overlay cloud storage system with file assured dele7on FADE key manager Data owner file metadata file (encrypted) Cloud FADE decouples key management and data management Key manager can be flexibly deployed in another trusted third party, or deployed within data owner No implementa7on changes on cloud

113 Threat Models and Assump7ons File assured dele7on is achieved If we request to delete a file, it is inaccessible Key manager is minimally trusted can reliably remove keys of revoked policies can be compromised, but only files with ac7ve policies can be recovered Data owner forms an authen7cated channel with key manager for key management opera7ons 113

114 Policy- based File Assured Dele7on Each file is associated with a data key and a file access policy Each policy is associated with a control key All control keys are maintained by a key manager When a policy is revoked, its respec7ve control key will be removed from the key manager 114

115 Policy- based File Assured Dele7on Main idea: File protected with data key Data key protected with control key data key control key File is maintained by the key manager 115

116 Policy- based File Assured Dele7on When a policy is revoked, the control key is removed. The encrypted data key and hence the encrypted file cannot be recovered data key Cannot be recovered without File The file is deleted, i.e., even a copy exists, it is encrypted and inaccessible by everyone 116

117 More Cloud Storage Security Related Topics Proofs of data redundancy Proofs of data encryp7on Assured dele7on Proofs of geoloca7on Proofs of ownership vs. deduplica7on More to be iden7fied 117

118 Proofs of Geoloca7on of Data Mo7va7on is from regulatory compliance. many laws requires storage providers to keep customer data within, say, na7onal boundaries One open problem is the remote verifica7on of the geographical loca7on of cloud data. of par7cular commercial interest

119 Proofs of Geoloca7on of Data Given the challenge of ensuring that data is not duplicated, any solu7on probably requires a trusted data- management system, e.g., via trusted hardware localizing the pieces of the above system. A promising explora7on direc7on Geoloca7on of trusted hardware via remote 7ming from trusted anchor points.

120 More Cloud Storage Security Related Topics Proofs of data redundancy Proofs of data encryp7on Assured dele7on Proofs of geoloca7on Proofs of ownership vs. deduplica7on More to be iden7fied 120

121 A_acks and Mo7va7ons Many cloud storage providers deduplicate the files that its users have stored online. Usually use file hash to detect and keep a single copy of original file save storage and bandwidth cost It s possible for adversary to simply leverage file hash to become one of the file owners.

122 A_acks and Mo7va7ons Cloud uses hash1 to detect future upload requests of File1 Upload file1 to cloud File1, hash1 Data owner

123 A_acks and Mo7va7ons Use hash1 to detect future upload requests of File1 Upload file1 to cloud File1, hash1 Request to upload File1, here is its hash1 Data owner adversary

124 A_acks and Mo7va7ons Use hash1 to detect future upload requests of File1 Upload file1 to cloud Data owner File1, hash1 Using simple file hash to become one of owners of File1 Request to upload File1, here is its hash1 adversary

125 Proofs of Ownership (POW) POW is Not proof of storage No- preprocessing step Client has less power and space The basic Idea: Server challenges the client client has to prove that he has the file With negligible probability client can convince server that he has the file when he does not

126 Solu7on Highlight Solu7on1: Proofs of random por7on of file Use Merkle Hash Tree (MHT) over file Client sends root of MHT, built over blocks of the file Server asks for random leaves to verify If small file entropy, encode the file first with erasure code to enlarge the unknown file por7on, making it less predictable Solu7on 2: Proofs of random por7on of summary of file Assume user s memory size to be a buffer Build MHT over the buffer only Other advanced solu7ons are also proposed

127 To learn more K. Bowers, M. van Dijk, A. Juels, A. Oprea, and R. Rivest. How to Tell if Your Cloud Files Are Vulnerable to Drive Crashes. In Proc. Of CCS, M. van Dijk, A. Juels, A. Oprea, R. Rivest, E. Stefanov, N. Triandopoulos, Hourglass Schemes: How to Prove that Cloud Files Are Encrypted. In Proc. Of CCS, 2012 Y. Tang, P. P. C. Lee, J. C. S. Lui, R. Perlman, Secure Overlay Cloud Storage with Access Control and Assured Dele7on, IEEE TDSC, vol. 9 no. 6, 2012, pp A. Juels, A. Oprea, New approaches to security and availability for cloud data. Commun. ACM 56(2): (2013) S. Halevi, D. Harnik, B. Pinkas, A. Shulman- Peleg, Proofs of ownership in remote storage systems. In Proc. Of CCS, 2011

128 To learn even more A. Juels and B. Kaliski. Proof of Retrievability (PORs) for Large Files. In Proc. Of CCS 07. K. D. Bowers, A Juels, and A. Oprea: HAIL: a high- availability and integrity layer for cloud storage. ACM CCS 09. K. Bowers, A. Juels, and A. Oprea. Proofs of Retrievability: Theory and Implementa7on. In Proc. Of CCSW, G. Ateniese, S. Kamara, J. Katz, Proofs of Storage from Homomorphic Iden7fica7on Protocols. In Proc. Of ASIACRYPT, 2009, pp Y. Dodis, S. Vadhan, D. Wichs, Proofs of Retrievability via Hardness Amplifica7on. In Proc. Of TCC, 2009, pp G. Ateniese, et al., Remote data checking using provable data possession. ACM Trans. Inf. Syst. Secur. 14(1): 12 (2011) H. Shacham, B. Waters, Compact Proofs of Retrievability. J. Cryptology 26(3): (2013)