Download presentation

Presentation is loading. Please wait.

Published byRodney Montgomery Modified over 2 years ago

1
**PORs: Proofs of Retrievability for Large Files**

Ari Juels RSA Laboratories Burt Kaliski EMC Innovation Network © 2007 RSA Laboratories

2
**The Subprime Mortgage Debacle**

Banks issued dubious mortgages to customers Banks packed mortgages as securities and sold them They “outsourced” risk But risk came home to roost… E.g. Bank of America’s Q3 ’07 earnings dropped 32% The moral: Risk is passed around in complex, difficult-to-trace ways…

3
**Storage-as-a-Service (SaaS)**

! MegArchive Corp. Seattle, USA My Wedding Photos Alice Peer-to-peer network MiniFile Inc. Bangalore, India One day, Alice’s machine crashes, so she contacts MegArchive… Bob Liverpool, UK

4
**Other financially motivated service degradation**

MegArchive moves Alice’s file to a slow disk array File is there, but retrieval is unacceptably slow MegArchive uses cheap storage that degrades over time MegArchive throws away a portion of Alice’s file to save space Most users don’t retrieve their backup files anyway

5
**PORs: Proofs of Retrievability**

Alice would like to ensure that her file F is retrievable She may also want to ensure compliance with a Service-Level Agreement (SLA) The simple approach: Alice periodically downloads F This is resource-intensive! What about spot-checking instead?

6
**Spot checking: Preparation**

Archive f2 f2 f1 f3 f1 f3 F Alice

7
**Spot checking: Verification**

Archive ~ f1 ~ ~ f2 f3 ~ F Alice = ? f1 f2 f3

8
**Spot checking: Verification**

Archive ~ f1 ~ ~ X f2 f3 ~ F Alice f1 f2 f3

9
**F Spot checking ~ ~ f1 ~ ~ f2 f3 f1 f2 f3 Pros: Cons:**

Archive ~ f1 ~ ~ f2 f3 Pros: Alice needn’t download all of F Can detect large erasure / corruption F ~ Cons: Alice must store chunks of F Can’t detect small erasure / corruption Alice f1 f2 f3

10
**MAC refinement: Preparation**

Archive f2 f1 f3 c2 c3 F MACk[f1] c1 Alice k

11
**MAC refinement: Preparation**

Archive f2 f1 f3 F MACk[f1] c2 c1 c3 Alice k

12
**MAC refinement: Preparation**

Archive f2 f1 f3 c2 c1 c3 F Alice k

13
**MAC refinement: Verification**

Archive f2 f1 f3 c1 c2 c3 F ~ F Pros: Alice needn’t store any of F Can detect large erasure / corruption Alice k Cons: Can’t detect small erasure / corruption

14
*** F F Error correcting code**

Archive * F parity bits decoder F With ECC to encode F → F*, big error in F* induces small error in F In effect, we can amplify errors in stored file

15
**ECC + MAC [loosely like LIBBI ’03, NR ’06]**

Archive f2 f1 f3 parity bits f4 c4 c1 c2 c3 F* F Pros: Alice needn’t store any of F—only key k Alice can detect even small corruption in F (= large corruption in F*) Alice k

16
**ECC + MAC: Verification**

Archive f2 f1 f3 parity bits f4 c4 c1 c2 c3 F* F Example: ECC corrects up to 10% corruption Alice checks 30 positions Each check detects corruption with probability ≥ .9 Alice detects insurmountable corruption with prob. ≥ > 95% Alice k

17
**A challenge Applying such an ECC to all of F is impractical**

Instead, we can stripe the ECC We’ll need many stripes for efficiency But then a clever adversarial archive can corrupt selectively…

18
**F* F Selective corruption c1 c2 c3 c4**

Archive c1 c2 c3 c4 F* F Adversary corrupts just one stripe S File is now irretrievable! Unless Alice checks S, she does not detect corruption If S is tiny fraction of file, adversary escapes detection with high probability

19
**Solution: Hide ECC stripes**

Archive c1 c2 c3 c4 F* F Do secret, randomized partitioning of F into stripes E.g. use secret key to generate pseudorandom permutation and then choose stripes sequentially Encrypt and permute parity bits In paper, we permute and encrypt F too, but not strictly necessary F itself is untouched, i.e., intact within F*! But adversary does not know where stripes are, so Adversary cannot feasibly target a stripe!

20
**Another challenge: How do we formally define a POR?**

Adversary may respond correctly to challenges, but deny service on retrieval! No global solution: Pattern / number of requests betrays nature of request A practical approach to definition: Assume memoryless adversary, e.g., software that can be rewound/reset Ensure that challenge interface is identical to retrieval interface, i.e., formal extraction model Limit distinction to pattern / number of requests

21
**Yet another challenge: Bandwidth**

As Alice makes many checks, she fetches many file pieces fi Can we reduce bandwidth? One approach: MAC on server side For ith check, generate one-time MACing key ki = g(k) Let archive compute and return m’i = MACk [fi] and E[mi] Alice checks that m’i = mi To preserve extraction interface, Alice must also request and check a (small) piece of fi i

22
**Another bandwidth-limiting approach: Sentinels**

F Insert hidden, random sentinel blocks into encryption of F Idea: Check sentinel blocks instead of file blocks Theoretically interesting because POR independent of F! Compare with proof of knowledge… Interesting in practical sense because sentinels can be combined Archive can XOR sentinels before sending Allows for, e.g., hierarchical POR (In paper, we permute F too, but not strictly necessary)

23
**Further / related research**

Implementation F may be too large to fit in main memory Quantifying QoS guarantees File updates: PORs break! Efficient fix? Extended models E.g., publicly verifiable Algebraic approaches Burns et al., CCS ’07 (next talk!) and other previous work [E.g., FB ’06]

Similar presentations

OK

HAIL (High-Availability and Integrity Layer) for Cloud Storage

HAIL (High-Availability and Integrity Layer) for Cloud Storage

© 2017 SlidePlayer.com Inc.

All rights reserved.

Ads by Google

Ppt on writing summary Ppt on second law of thermodynamics entropy Ppt on national sports day Ppt on urinary tract infection in children Ppt on revolution of the earth and seasons quiz Ppt on carbon dioxide laser Ppt on web services testing Ppt on network traffic management Ppt on electrical transformer manufacturing Ppt on vision and mission