Speaker : YUN–KUAN,CHANG Date : 2010/08/05 Scalable and Efficient Provable Data Possession.

Speaker : YUN–KUAN,CHANG Date : 2010/08/05

Scalable and Efficient Provable Data

Possession

Outline 1/2

2

MotivationContributionsProposed PDP scheme

NotationSetup phaseVerification Phase

Supporting dynamic outsourced dataBlock UpdateBlock DeletionBatching Updates and DeletionsSingle-Block Append

Outline 2/2Insert

比較兩 PDP

3

Motivation 1/2Data generation is currently outpacing storage availability.

In contrast, a well-designed PDP scheme would be, at the same time, secure and scalable/efficient.

Alice wants to outsource her life-long collection of digital content to a third party, giving read access to her friends and family. Alice wants to make sure that her data is faithfully stored and readily available.

4

Motivation 2/2To verify data possession, Alice could use a resource-constrained personal device.

In this realistic setting, our two design requirements are very important.

(1) outsourcing data in clear-text(2) bandwidth and computation efficiency

5

ContributionsThis paper’s contribution is two-fold:1. Efficiency and Security:

the proposed PDP scheme , relies only on efficient symmetric-key operations in both setup (performed once) and verification phases.

our scheme is more efficient than POR as it requires no bulk encryption of outsourced data and no data expansion due to additional sentinel blocks

2. Dynamic Data Support: the new scheme supports secure and efficient

dynamic operations on outsourced data blocks, including: modification, deletion and append.

6

Proposed PDP scheme 1/2It consists of two phases: setup and verification.

Before outsourcing, OWN pre-computes a certain number of short possession verification tokens.

The actual data is then handed over to SRV. Subsequently, when OWN wants to obtain a proof of data possession, it challenges SRV with a set of random-looking block indices.

7

Proposed PDP scheme 2/2In turn, SRV must compute a short integrity check over the specified blocks (corresponding to the indices) and return it to OWN.

OWN’s storage overhead is constant regardless of the size of the outsourced data.

Our scheme is also very efficient in terms of computation and bandwidth.

8

Notation

9

D outsourced data D[1], . . . ,D[d]

OWN the owner of the data

SRV server

H(·) cryptographic hash function SHA-1, SHA-2

AEkey(·) an authenticated encryption scheme

that provides both privacy and authenticity

AE−1key(·) decryption operation for the

scheme

fkey(·) PRF indexed on some (usually secret) key.

gkey(·) PRP indexed under key.

log

log

128

l d

c t

L

:{0,1} {0,1} {0,1}c k Lf

:{0,1} {0,1} {0,1}l L lg

Setup phase 1/2We use the PRF with two master secret keys and , both of bits. The key is used to generate session permutation keys while is used to generate challenge nonces.

During the Setup phase, the owner OWN generates in advance possible random challenges and the corresponding answers. To produce the token, the owner generates a set of indices.

10

tthi

r

f

ZZ

WWk

Setup phase 2/2

11

Choose parametersfunctionsthe number of tokensthe number of indices per verificationgenerate randomly master keys

For ( to ) do begin

end for

Store

, , ,c l k L,f g

tr

, , {0,1}kW Z K

1i tRound i( )i Wk f i( )i Zc f i

( , 1 ,..., )i ii i k kv H c D g D g r

' ,i K iv AE i v'( ,{[ , ] 1 })iD i v i t

, , ,W Z K i

Verification Phase 1/2

12

begin

check end

Challenge i

( )i Wk f i( )i Zc f i

,i ik c

( , 1 ,..., )i ii k kz H c D g D g r

', iz v

1 'K iv AE v

( , )v i z

Verification Phase 2/2We point out that there is almost no cost for OWN to perform a verification.

It only needs to re-generate the appropriate pair (two PRF-s invocations) and perform one decryption in order to check the reply from SRV.

The computation cost for SRV, though slightly higher ( PRP-s on short inputs, and one hash), is still very reasonable.

13

,i ik c

r

Supporting dynamic outsourced data

This leads us to consider various data block operations (e.g., update, delete, append and insert) and the implications upon our scheme which stem from supporting each operation.

One obvious and trivial solution to all dynamic operations, is (for each operation) for OWN to download from SRV the entire outsourced data D and to re-run the setup phase.

14

Block Update 1/3We assume that OWN needs to modify the -th data block which is currently stored on SRV, from its current value to a new version, denoted .

The remaining verification tokens, OWN needs to factor out every occurrence of D[n] and replace it with D'[n].

One subtle aspect is that OWN cannot disclose to SRV which (if any) verification tokens include the -------th block.

15

n

[ ]D n '[ ]D n

n

Block Update 2/3we require OWN to modify all remaining verification tokens. We also need to amend the token structure as follows.

from:

to:

16

( , 1 ,..., )i ii i k kv H c D g D g r

' ( , )i Kv AE i v

( ,1, 1 ) ... ( , , )i ii i k i kv H c D g H c r D g r

' ( , , )i K iv AE ctr i v

Block Update 3/3

17

assume that block is being modified to

begin

ctr=ctr+1 for do

for do if then

end

[ ]D n

( ,1, 1 ) ... ( , , )i ii i k i kv H c D g H c r D g r

'{[ , ] |1 }ii v i t

' 1 'K iz AE v

( )i Wk f i( )i Zc f i

1j to r

1i to t

ik

g j n

'( , , ) ( , , )i ii i i k i kv v H c j D g n H c j D g n

' ( , , )i K iv AE ctr i v ' ', ,{[ , ] |1 }ik in D g n i v i t

'[ ]D n

Block Deletion 1/2After being outsourced, certain data blocks might need to be deleted.

Deleted blocks can be replaced by a predetermined special block in their respective positions via the update procedure.

from:

to:

18

'( , , ) ( , , )i ii i i k i kv v H c j D g n H c j D g n

( , , ) ( , , )ii i i k iv v H c j D g n H c j DBlock

Block Deletion 2/2

1919

assume that block is being modified to

begin

ctr=ctr+1 for do

for do if then

end

[ ]D n ( ,1, 1 ) ... ( , , )

i ii i k i kv H c D g H c r D g r

'{[ , ] |1 }ii v i t

' 1 'K iz AE v

( )i Wk f i( )i Zc f i

1j to r

1i to t

ik

g j n

' ( , , )i K iv AE ctr i v ( , , ) ( , , )

ii i i k iv v H c j D g n H c j DBlock ', ,{[ , ] |1 }in DBlock i v i t

Batching Updates and DeletionsIt is clear that the cost of updating all remaining verification tokens for a single block update or deletion is not negligible for OWN.

Any number of block updates and deletes can be performed at the cost of a single update or delete.

To do this, we need to modify the for-loop to take care of both deletions and updates at the same time.

20

Single-Block Append 1/4The owner might want to increase the size of the outsourced database.

we could consider a logical bi-dimensional structure of the outsourced data, and append a new block to one of the original blocks in a round-robin fashion.

21

1 ,...,D D d

Single-Block Append 2/4Assume that OWN has the outsourced data

, and that it wants to append the blocks .

22

1 ,...,D D d

1 ,...,D d D d k

'

'

'

'

1 1 , 1

2 1 , 2

1 ,

D D D d

D D D d

D k D D d k

D d D d

Single-Block Append 3/4For the index in the -th challenge, the server will have to include in the computation of the XOR-ed hashes vi any blocks linked to , i.e., the entire row in the logical matrix above. In particular, SRV will include:

is the length of the row of the logical matrix.

23

j i

ik

D g j

ikg j

( , , ) ( , , ) ( , , )i i ii k i k i kH c j D g j H c d j D g j d H c d j D g j d

ik

g j

Single-Block Append 4/4The advantage of this solution is that we can just run the Update operation to append blocks so we can even batch several appends.

The drawback is that the storage server will have to access more blocks per query and this may become increasingly expensive for SRV as the number of blocks appended to the database increases.

24

InsertA logical insert operation corresponds to an append coupled with maintaining a data structure containing a logical-to-physical block number mapping for each “inserted” block.

Inserting a block corresponds to shifting by one slot all blocks starting with index .

This affects many rows in the logical matrix described above and requires a substantial number of computations.

25

D j

1j

比較 – Setup

上一篇的 PDP 本篇的 PDP

Owner Owner

計算 Data 裡每一個區塊的標籤 計算 Data 裡每回合 r 個標籤

傳送 pk,F,Σ( 標籤的連結 ) 給Server

傳送 D,[i,v'] 給 Server

刪除 F, Σ 儲存 W,Z,K,i ( 每回和相同 )

回合數 t 如果沒太大，可以儲存 v'

26

比較 – Challenge

上一篇的 PDP 本篇的 PDPOwner Owner

選擇 Data 裡第 c 個區塊來挑戰 選擇第 i 回合來挑戰

計算方式不同

Server Server

計算方式不同

27