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: SentinelsF
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]