98

Chapter 5 Dynamic Public Audit Protocols

5.1. Introduction

In this chapter, we propose dynamic public audit protocols to ensure data storage security in

cloud computing with the support of public verifiability and efficient dynamic data operations at

block level. In these protocols, the verifier (TPA) verifies the Integrity of data in the cloud on

behalf of Clients using their public key. We have classified these protocols into two types:

1) RSA-based Dynamic Public Audit Protocol: its designed based on RSA-public key

cryptography [139,173] to ensure the Availability and Integrity of data stored in Cloud with

support of public verifiability and efficient dynamic data operations. This protocol is useful

where an application demands Integrity and Availability of data with efficient dynamic data

operations through public verifiability. However, it is not suitable for the resource constrained

devices due to the large key size when they need confidentiality of data.

2) ECC-based Dynamic Public Audit Protocol. Its designed based on Elliptic Curve

Cryptography (ECC)[ 130,173] instead of RSA to address the Confidentiality, Availability and

Integrity of data stored in Cloud. It is useful where application needs Confidentiality,

Availability and Integrity of data efficiently and mainly it is suitable for resource constrained

mobile devices in cloud computing like PDA, Smart-Cards and note books.

In Table 5.1, we shown the difference between the RSA and ECC based Protocols

Table 5.1: Difference between the RSA-based Protocol and ECC-based Protocol

Parameters RSA-based Protocol ECC-based Protocol

Availability Yes Yes

Integrity Yes Yes

Confidentiality No Yes

The detailed description of these protocols is given in sections 5.3 and 5.5 respectively.

99

5.2. Preliminaries

5.2.1. RSA Assumption

The RSA assumption[69, 189] is that the RSA problem is hard to solve when the modulus

N is sufficiently large, randomly generated, and the plaintext m is a random integer between

0 and N − 1. Let k be the security parameter. Let positive integer N be the product of two k-bit,

distinct odd prime‘s p, q. Let e be a randomly chosen positive integer less than and relatively

prime to )(N . The Given (N, e) obtaining a value y such that y≠x, it is hard to compute x such

that

y= xe mod N. (5.1)

Clearly, the given an RSA public key (N, e) and a cipher text y= xe mod N, it‘s hard to

compute RSA private key when the modulus N is sufficiently large and randomly generated i.e.

N=1024, [77,189].

For example:s let p=17 and q=11

Then n=pq=17×11=187

Ø(n)=(p-1)(q-1)=16×10=160

We Choose e=7

Then de=1(mod 160)

Then d = 23, because 23x 7 = 161 = 10 x 160 + 1; d can be calculated using the extended

Euclid's algorithm

PK={7, 187} PR={23,187}

The Encryption is 887 mod 187=11 ciphertext

And Decryption is 1123

mod 187=88 plaintext

5.2.2. ECC over ring Zn

The principal attraction of ECC[88], compared to RSA, is that it appears to offer equal

security for a far smaller key size, thereby reducing processing overhead. On the other hand,

although the theory of ECC has been around for some time, it is only recently that products have

begun to appear and that there has been sustained cryptanalytic interest in probing for

weaknesses. Accordingly, the confidence level in ECC is not yet as high as that in RSA.

Let n be an integer and a, b be two integers in Zn such that

gcd(4a3+27b

2, n)=1. (5.2)

100

An elliptic curve En(a, b) over the ring Zn is the set of points(x, y) Zn× Zn satisfying the

equation:

y2=x3+ax+b (5.3)

together with the point at infinity denoted as On.

For example [173], let p = 23 and consider the elliptic curve y2 = x

3 + x + 1. In this case,

a = b = 1. For the set E23(1, 1), we are only interested in the nonnegative integers in the

quadrant from (0, 0) through (p1, p1) that satisfy the equation mod p. Table 5.1 lists the points

(other than O) that are part of E23(1,1) and Fig. 5.1 plots the points of E23(1,1).

Table 5.2: Points on the Elliptic Curve E23 (1, 1)

(0,1) (6,4) (12,9)

(0,22) (6,19) (13,7)

(1, 7) (7,11) (13, 16)

(1, 16) (7, 12) (17, 5)

(3,20) (9, 7) (17, 20)

(3, 13) (9, 16) (18, 3)

(4, 8) (11, 3) (18, 20)

(5,4) (11, 20) (19,5)

(5,19) (12,4) (19,18)

The security of elliptic curve cryptography depended on the Finding order of elliptic curve

and Elliptic curve discrete logarithm problem denoted by ECDL problems [173].

a) Finding the order of elliptic curves

The order of elliptic curve over the ring Zn is: let n=pq is defined in [127] as

Nn =lcm(#Ep(a, b), #Eq(a, b)). Nn is the order of the curve, i.e. for any Pε En(a, b) and any

integer k, such that

(k Nn+1)P=P. (5.4)

If(a=0 and p≡q≡2 mod 3) or (b=0 and p≡q≡3 mod 4), the order of En(a, b) is equal to Nn. The

given

Nn =lcm(#Ep(a, b), #Eq(a, b))= lcm(p+1, q+1) (5.5)

101

Solving Nn is computationally equitant to factoring the corresponding number n.

Fig. 5.1 The Elliptic Curve E23(1,1)

b) Elliptic Curve Discrete Logarithm Problem (ECDLP)

Consider the equation

Q=rP (5.6)

where Q, Pε En(a, b) and r<n. it is relatively hard to determine r given Q and P.

For example, we Consider the group E23 (9, 17). This is the group defined by the equation:

y2 mod 23 = (x3 + 9x + 17) mod 23. What is the discrete logarithm k of Q = (4, 5) to the base

P = (16,5)? The brute-force method is to compute multiples of P until Q is found.

Thus P = (16, 5); 2P = (20, 20); 3P = (14, 14); 4P = (19, 20); 5P = (13, 10); 6P = (7, 3); 7P =

(8, 7); 8P (12, 17); 9P = (4, 5). Because 9P = (4, 5) = Q, the discrete logarithm Q = (4, 5) to the

base P = (16, 5) is k = 9. In a real application, k would be so large as to make the brute-force

approach infeasible.

102

5.2.3. Homomorphic Verifiable Tags (HVTs)

A HVT[13] is a computing tags for multiple blocks, which can be combined into a single

value, the HVT for a given message mi, is denoted by Ti. The Homomorpic Verifiable Tags

having the following two properties:

a) Block-Less Verification: By using HVTs, the server can construct an Integrity proof on

certain file blocks, while Clients or verifier no need to have access the actual file blocks.

b) Homomorphic Tags: For the given two values imT and

jmT , anyone can combine them

into the tag ji mmT can be generated by combining ji mm , corresponding to the sum of the

messages.

In RSA-based protocol, we use a RSA-based HVT [66], which is defined as follows. The

RSA-based HVT for message mi is defined as

NgT i

i

m

m mod (5.7)

Its homomorphic property can be deduced from its definition. When imT and

jmT are tags of

mi and mj respectively, the tag for mi+mj can be generated by computing:

Ng

NgNg

TTT

ji

ji

jiji

mm

mm

mmmm

mod

)mod()mod(

)()()(

(5.8)

In ECC-based protocol, we use ECC-based HVT [127] for message mi is defined as

NPmT imimod . Its homomorphic property can be deduced from its definition. When

imT and

jmT are tags of mi and mj respectively, the tag for mi+mj can be generated by computing:

NPmm

NPmNPm

TTT

ji

ji

mmmm jiji

mod)(

)mod)(mod(

)()()(

(5.9)

Using these preliminaries, we propose RSA-based and ECC-based dynamic audit

protocols, which will be explained in sections 5.3 and 5.5 respectively.

103

5.3. RSA-based Dynamic Public Audit Protocol (RSA-DPAP)

This protocol ensures the Availability and Integrity of data stored in the cloud using RSA-

public key cryptography to support public verifiability, in which TPA can verify the Integrity of

data on behalf of the Clients using their public key and supports efficient dynamic data

operations at block level. It consists of three phases:

1) Setup Phase: in which, the Client encodes the file for the data Availability, generates the

private key and public key pair based on RSA-assumption and computes the metadata for the

Integrity verification

2) Verification Phase: in which, the TPA verifies the Integrity of data through challenge-

response protocol

3) Dynamic Data Operations and Verification Phase: in which, the Client updates the file

stored in the cloud without retrieving it.

The detailed descriptions this phase are explained in next sections.

Fig.5.2. Architecture of RSA-based Dynamic Public Audit Protocol

Client

TPA

CSP

(a) Encoding (b)Key generation (c) Encryption* (d)Metadata

Generation

(a)Challenge (b)Response (c)CheckIntegrity

(a)PrepareUpdate (b)ExecuteUpdate (c)UpdateChallenge (d)UpdateResponse (e)CheckUpdate

Setup Phase

Verification Phase

Dynamic Data Operations and Verification Phase

*indicates the optional

104

5.3.1. Setup Phase: RSA-DPAP

In this protocol, the setup phase consists of three methods as shown in Fig 5.2:

a)Encoding b) KeyGeneration c) MetadataGeneration. The Encoding algorithm same as

algorithm 4.1 for RSA-DPAP protocol.

a)KeyGeneration: RSA-DPAP

In this method, the Client generates secrete key and public key pair based on RSA-

assumption as follows:

1) The Client chooses the two prime numbers p, q, then calculates

pqN (5.10)

N=pq be one publicly known RSA modulus, in which 1'2,1'2 qqpp two large

primes, then, 'p and 'q are also large primes.

2) In addition, the Client calculate

)1)(1()( qpN (5.11)

Then Select an integer g is a generator of multiplicative cyclic group

NZ , since

)(1[)1))(,gcd( NgNg and calculate the

)(mod1 Nge (5.12)

Finally, generates a Public key ),( Ngpk and secrete key ),( Nesk . The detail of

key generation algorithm is given in algorithm 5.1.

Algorithm 5.1: KeyGen(1k)→(pk, sk): RSA-DPAP 1: Procedure: KeyGen 2: choose parameters p, q; 3: calculate N=p×q 4: calculate )1)(1()( qpN

5: choose random integer g )](1[ Ng

6: )1))(,gcd( Ng

7: calculate )(mod1 Nge

8: generate public key },{ Ngpk

and secrete key },{ Nesk

9: end Procedure

105

b) MetadataGeneration: RSA-DPAP

After generating public and private key pair, the Client computes the metadata(verification

tags) for each block of the file F={m1,m2,…,mn} using public key, private key by executing

algorithm 5.2, which is similar to metadata computation algorithm 4..2 in chapter 4. Here, we

use RSA-based Homomorpic Verification Tags (HVT) instead of Universal Hash Function

(UHF) which is more efficient than hash functions.

The procedure of the metadata generation given in algorithm 5.2 as follows:

NgT im

i mod (5.13)

We denote the set of tags by

},....,,{ 21 nm TTTT where mε[1,n] (5.14)

Algorithm 5.2: MetadataGen(pk,sk,mi)→Ti : RSA-DPAP /* let F={m1,m2,…,mn}*/ 1: Procedure: MetadataGen 2: for i←1, n do

3: Compute NgT im

i mod

4: end for

5: end procedure

Fig.5.3. Setup Phase: RSA-DPAP

Client TPA CSP 1. Client generate a key pair sk={e,N}, pk={g, N}

2. Client computes metadata by running MetadataGen

Algorithm NgT im

i mod 3. Sends F=(m1,m2,…mn) to server

4. Send pk, Tm to TPA

5. The TPA stores Tm and pk for later processing

6. The server stores the file F in cloud

7. Client stores the private key and deletes file F and metadata Tm from locally

106

After pre-processing the file, the Client sends the file F to the CSP, and sends Tm , public

key to the TPA for later verification. Then, deletes them from its local storage and keeps private

key as secret. The CSP stores the data file F while The TPA stores the metadata and public key.

The process of Setup phase is depicted in Fig. 5.3.

5.3.2. Verification Phase: RSA-DPAP

In verification phase, the Third Party Auditor (TPA) must checks the Integrity of stored data

in the cloud through Challenge-Response rotocol instead of the Client to reduce the verification

burden in homomorpic distribution verification protocol, which was discussed in 4th

chapter.

This phase consists of three methods as given in Fig 5.2:

a) Challenge b) Response c) CheckIntegrity

a) Challenge: RSA-DPAP

In this method, The TPA issues a ―random sampling‖ challenge using Sobol sequence to

the CSP to verify the Integrity of data stored in the cloud by executing algorithm 5.3 as follows:

The TPA generates two sobol random keys kSRF and kSRP using Sobol sequence [27] and

computes random indices c-element subset j= {s1,….,sc} of the set[1,n], where

SRPkqs (q) (5.15)

for 1≤q≤c and kSRP is a randomly chosen key, whose indices are randomly chosen for each

challenge. This prevents the server from the anticipating which blocks will be queried in each

challenge. The TPA also chooses fresh random element sεZn to ensure that server does not reuse

any values from a previous challenge and compute.

Ngg s

s mod (5.16)

Then, the TPA sends challenge chal={(j, kSRF, gs)} to the CSP and waits for a response

where the message ―chal‖ specifies the specific positions of the distinct blocks that are required

to be verified. The TPA must discard the ―chal‖ message after use; otherwise the cloud service

provider may cheat by previously cached result.

107

Algorithm 5.3: Challenge: RSA-DPAP 1. Procedure: Challenge(j, kSRF, gs )← chal 2. Generates a random keys kSRF, kSRP and fresh random value using Sobol Sequence. 3. Compute

SRPkqs (q)

4. Choose fresh random element sεZn

5. Compute Ngg s

s mod

6. Create challenge chal=(j, kSRF, gs ) 7. end procedure

b) Response: RSA-DPAP

In this method, the CSP computes the Integrity proof for a challenge chal={(j, kSRF, gs)}

after receiving it from the TPA as follows: the CSP runs the algorthm 5.4 to generates a

response (Integrity proof) of data stored in the cloud. The procedure of generating response is:

specifically, the CSP generates sequence of block index-coefficients a1,a2,…an by using Sobal

Random Function(SRF) i.e

)( jfa

SRFkj (5.17)

where iε[s1,….,sc] . Then computes

j

c

i

s

sj

jmar

1

. (5.18)

Ng

NgR

ji

cs

sjjma

s

r

s

mod)(

mod

1

(5.19)

server returns R to the TPA.

Algorithm 5.4: Response (pk,F,chal)→R: RSA-DPAP 1: Procedure: GenProof 2: for j←s1, sc do 3: generate )( jfa

SRFkj

4: end for

5: compute j

c

i

s

sj

jmar

1

6: compute NgR r

s mod

7: end procedure

108

c) CheckIntegrity: RSA-DPAP

After receiving a response from the CSP, the TPA runs algorithm 5.5 to validate the

Integrity of data as follows:

i) The TPA regenerates the index blocks

)( jfaSRFkj

(5.20)

where jε[s1,….,sc] using Sobol Random Function(SRF),

ii) Then Computes

NmTPc

j

s

sj

a

ji mod)(1

(5.21)

and

NPR s mod' (5.22)

Next, verifier checks whether RR ' . (5.23)

If condition (5.23) is verified, the Integrity of data is ensured, otherwise data is corrupted.

Algorithm 5.5: CheckIntegrity(pk,Tm,chal, R)→{0, 1}: RSA-DPAP 1: Procedure: Checkproof

2: for j←s1, sc do

3: Re-generate )( jfaSRFkj

4: end for

5: Computes NmTPc

j

s

sj

a

ji mod)(1

6: Computes NPR s mod'

7: if (R'=R) 8: return 1 9: else 10: return 0 11: end if 12: end procedure

109

The Integrity of above equation (5.23) can be elaborated as follows:

Where NPR s mod'

NgP

NNg

NmTP

ji

cs

sjj

cjji

c

j

ma

s

sj

am

s

sj

a

ji

mod

mod)mod(

mod)(

1

1

1

(5.24)

Substitute the P value in equation (5.22)

RR

R

Ng

NNg

NPR

ji

cs

sjj

ji

cs

sjj

ma

s

mas

s

'

mod)(

modmod

mod'

1

1

It is clear that the data has been not modified or deleted. Therefore, the data is safe in the

cloud. The process of verification phase is illustrated in Fig.5.4.

Fig.5.4. Verification Phase: RSA-DPAP

(5.26)

(5.27)

(5.25)

TPA CSP 1. TPA genates a challenge

chal=( j, kSRF, gs)

and sends to theserver. (j, kSRF, gs)

Challenge request chal

2. Generates )( jfaSRFkj where i=[s1,sc]

3. Computes j

c

i

s

sj

jmar

1

.

4. Computes NgR

cs

sijijma

s mod1

NgR r

s mod

Integrity Proof R

5. Re-generate SRFkfa j (j ) using kSRF

6. Computes NmTP

c

j

s

sj

a

ji mod)(1

7. Computes

NPR s mod'

8. Verify if R'=R returns ‘1’ otherwise ‘0’

110

The above three algorithms used for the static data Integrity verification but cloud data

storage is dynamic data storage. The next section will describe the dynamic structure of RSA-

DPAP

5.3.3. Dynamic Data Operations and Verification Phase: RSA-DPAP

In clouds, one of the core design principles is to provide dynamic scalability for various

applications. This means that remotely stored at might be not only accessed but also

dynamically updated by the Clients without retrieving original data. The Data Dynamics

include: Block Modification (BM), Block Insertion (BI), and Block Deletion (BD) operations.

However, it is crucial task of updating data file at cloud without effecting remaining data and

maintaining the same Integrity assurance. Like protocols [56, 66, 169], RSA-DPAP scheme also

supports dynamic data updates at block level. Hence, each block metadata depends only on the

block content mi, and not on the block index and any other blocks.

From the Fig. 5.2, this phase consists of three phases: a) PrepareUpdate b) Execute Update

c) UpdateChallenge d) UpdateResponse e) CheckUpdate

a) PrepareUpdate : RSA-DPAP

In order to update data in the cloud, the Client creates a request and sends to the CSP. To

prepare an update request for the particular update operation (modification/insert/delete), the

Client runs the algorithm 5.6 and do the following:

a) If update operation is Block Modification:

1) Create a new block mj

2) Compute new metadata using equation

Nmod' jj mT (5.28)

3) Create update request (BM, j, mi) and sends to the server.

4) The Metadata sends to TPA for later verification

b) If the update operation is Block Insertion, the Client does the following:

The Client wants to insert a new block m* after position j in the file F'= {m'1,..,m'n}.

1. Create a new block m*j

2. Compute new metadata

njj NPmT mod'* (5.29)

111

3. Create update request (BI, j, m'i) and sends to the server

4. The metadata sends to the TPA for later verification

Algorithm 5.6: PrepareUpdate : RSA-DPAP 1. Procedure:PrepareUpdate←(BM/BI/BD,j, m'i) 2. Select a update block mj 3. if(update==modification/insert) 4. Compute njj NPmT mod'

5. Update=(BM/BI, j, m'i) 6. else if(update==deletion) 7. Update =((BD, j) 8. Send update request to the server 9. end if

10. end procedure

The block insertion operation changes the logical structure of the file; the RSA-DPAP can

perform the block insertion operation without re-computing metadata of all the blocks that have

been shifted after inserting a block, because block index is not included in the metadata.

c) If the update operation is Block Deletion, the Client creates the update request as delete

request (BD, j), sends to the server and also sends a request to the TPA to delete

corresponding block metadata where j is the block to be deleted. When one block is

deleted, all subsequent blocks are moved one step forward.

b) ExecuteUpdate: RSA-DPAP

Upon receiving an update request from the Client, the CSP updates the file in the based on

Client request by running algorithm 5.7 as follows: if update request is modification, the CSP

replace the block m'i with m'j or if update is an insert operation, the CSP inserts the new block

before or after the particular block, if it is delete, then the CSP deletes the particular block from

the file and move all the blocks backward after the block.

112

Algorithm 5.7: ExecuteUpdate : RSA-DPAP 1. Procedure: ExecuteUpdate←{F''} 2. if(update==modification) 3. replace mi with m'j in the file F' 4. update file F'' 5. else if(update==insert) 6. insert m*x before mi or append 7. else if(update==deletion) 8. delete mi from file F' 9. update the file F'' 10. move all blocks backward after ith block 11. end if 12. end procedure

c) UpdateChallenge : RSA-DPAP

After updating the data in cloud, the Client wants to know whether the server has updates

the data successfully or not?, then, the Client immediately asks the server for the proof of update

operation as given algorithm 5.8 follows:

If Client wants verify the update proof of block j, then Client sends {sk, j} to the sever.

d) UpdateResponse : RSA-DPAP

Upon receiving a request from the Client, the server computes a response for updated block

and returns to the Client by executing algorithm 5.8 as follows: if update operation is

modification or insertion then the server computes:

NmR jj mod' (5.30)

Or if the update operation is deletion, then the server do nothing i.e. the verification directly

starts from the static case.

e) CheckUpdate : RSA-DPAP

To ensure the security of dynamic data operations, the Client verifies the Integrity of

updated block immediately after updating the data by runing the algorithm 5.8 as follows:

After receiving an update response from the server, the Client verifies whether if(Tj=Rj), if it

returns true, CSP has been updated data successfully otherwise not.

113

If the CSP has updated the data successfully, the Client sends updated metadata to the TPA

for later Integrity verification.

Algorithm 5.8 : CheckUpdate : RSA-DPAP 1. Procedure: VerifyUpdate(pk, Q, R')→{1,0 } 2. if(updatechallenge==modification/insert) 3. client sends {sk, j} to the sever 4. server computes response and sends client

NmR jj mod'

5. client check if(updatechallenge==modification/insert) 6. then if(Tj=Rj) 7. return 1 8. else 9. return 0 10. end if 11. else if(update==deletion) 12. verification directly starts from static case 13. end if 14. end procedure

The procedure of dynamic data operation is illustrated in Fig. 5.5.

Client TPA CSP

1. Computes NgT im

i mod''

update = (i, m'i,update/insert/delete), 2. Update request

3. Replaces mi' with mi

and update the file F'.

4. Computes NgR im

i mod''

5. NgR im

i mod''

Update Proof '

jR

6. . Verify if ''

ij RT

7. returns 1 otherwise 0 8. Send Tj' to the TPA 9. Delete m'i , Tj' and R'j

a. from locally 10. TPA replaces Ti with Tj'

6. Otherwise resends update request to the CSP.

Fig.5.5 Data Dynamics Data Operations and Verification Phase: RSA-DPAP

114

5.3. Analysis of RSA-DPAP

In this analysis, we analyze the security and performance of RSA-DPAP

5.3.1. Security Analysis of RSA-DPAP

In this section, we evaluate the Integrity of RSA-DPAP under the adversary model. Here,

we show that RSA-DPAP scheme is secure in a random oracle model against data modifications

or deletions. The following theorem and detection probability are guarantee that RSA-DPAP

scheme is secure in a random oracle model. Finally, compared to existing probabilistic

verification schemes, RSA-DPAP scheme provides better Integrity.

a) Integrity

We begin with the following lemma, which follows from the RSA-assumption.

Lemma 5.1: [66]. Given x, y ε Zn, along with a, b ε Z, such that xa = y

b and gcd(a, b) = 1, there

is an efficient algorithm for computing z εZn such that za=y.

Definition 5.1: A Proposed system (Setup, Verification) built on a RSA-DPAP(KeyGen,

MetadataGen, Response, CheckIntegrity) guarantees that data Integrity if for any

PPT(probabilistic polynomial-time) adversary A. The probability that A wins the security game

on a set of file blocks is negligibly close to the probability that the Challenger B can extract

those file blocks via multiple challenge-responses by means of a knowledge extractor ε.

Security Game:

The security game played between the Challenger B who plays the role of the verifier and

the Adversary A who act as a server as follows:

Setup: The challenger runs KeyGen(1k)→(pk,sk), sends pk to the adversary and keeps sk as

secret.

Query: The adversary makes tagging queries adaptively: It selects a block m1 and sends it to the

challenger. The challenger computes the verification metadata. T1 ← Tag(pk, sk, m1) and

sends it back to the adversary. The adversary continues to query the challenger for the

verification metadata T1 , . . . , Tn on the blocks of its choice m1, ... ,mn. As a general rule, the

challenger generates Tm for some 1 ≤ m ≤ n, by computing Tm ← T (pk, sk,mi) where 1≤i≤n.

115

The adversary then stores all the blocks as an ordered collection of file blocks F = (m1, . ,mn),

together with the corresponding verification tags T1 , . . , Tn.

Challenge: The challenger generates a challenge chal and asks the adversary to provide a proof

of Integrity for the blocks mi, . . . ,mn determined by chal.

Forge: The adversary computes a proof of possession R for the blocks indicated by chal and

returns R.

If CheckProof(pk, Tm, chal, R) = 1, then the adversary has won the Data Possession Game.

Definition 5.2: KEA1-1(Knowledge of Exponent Assumption[13]): For any adversary A

that takes input(N, g, gs) and returns group of elements(C, Y) such that Y=C

s, there exists an

―extractor‖ A , which given the same inputs as A, returns x such that C=gx.

Theorem 5.1[13]. Under the Kea1-r assumption, and RSA assumption, the RSA-DPAP

scheme is secured in the random oracle model.

Proof: we prove this theorem according to the definition 5.1; assume that an adversary A

wins the game on challenge picked by B, then, show that B constructs the knowledge extractor ε

to extract the blocks determined by the challenge.

B simulates the protocol environment for A with the following steps:

Setup: The Challenger B generates a public key pk=(N,g) where g=y2 mod N and sends pk

to A.

Query: The Adversary A adaptively selects some file blocks mi from different queries, where

i=1, 2,…., n. and queries the verification tags from B. then B computes a NgT im

i mod

for each of these selected blocks and return to A. Then, the adversary stores all these

blocks as an ordered collection of the file blocks F = (m1, . . . ,mn), together with the

corresponding verification metadata T1 , . . . , Tn.

Challenge: B generates a chal for the file blocks {m1,…,mn} and sends it to A.

let chal={(j, kSRF, gs)}. where gs=gs mod N.

Forge: A computes a response R about the blocks m1,……,mn determined by j to prove the

Integrity of the requested blocks.

116

If CheckIntegrity(pk,Tm, chal, R)=“1”, then the adversary has won the security game.

Now, we show that RSA-DPAP protocol constitutes a knowledge extractor ε may extract

file blocks css ii mm

1

when css aa

1are pair wise-distinct. During the game, B has given (j, kSRF,

gs) to A, then A computes NgR

cs

sjjijma

s mod1

where )( jfa

SRFkj where s1≤j≤sc. Because, A

can naturally computes NgPji

cs

sjjma

s mod)( 1

from Tm. That is A has given (j, kSRF, g

s) as input

and produce outputs (R, P) that satisfies R' = Ps mod N.

From the KEA1-r assumption, B can construct an extractor ε to extract m, which is given

the same input as A, outputs c which satisfies

P = gc mod N (5.31)

where Nmacj

c

i

s

sj

j mod1

. (5.32)

Now, B creates n challenges (s1, kSRF1, gs), (s2, kSRF2, gs2). Then, computes SRFkfak

j (j )

for j ε [s1, sc] and k є [1, n]. Then, challenges A for n times, for example on the kth

time, B

challenges A with {sk kSRFk, gsk}. From A response, B extracts

.mod....2211

Nmamamaccscss i

k

si

k

si

k

sk

(5.33)

By choosing independent coefficientscss aa

1, in c executions of the protocol on the same

file blockscss ii mm

1, the extractor ε obtains c independent linear equations in the file blocks

css ii mm 1

(Note that each time ε runs the Integrity checking protocol, then he obtains linear

equations).

ni

n

si

n

si

n

s

isisis

isisis

cNmamama

cNmamama

cNmamama

cscss

cscss

cscss

mod....

mod....

.mod....

2211

2211

2211

2

222

1

111

(5.34)

117

The extractor ε may solve these equations to obtain each file blockscss ii mm

1

, then B gets

Mi*, which satisfies NmM

jii modfor any fragment mi of the file F. If ii MM , then

knowledge extractor ε has successfully extracted the all blocks css ii mm

1

.

Next, we analyze the case, suppose if ii MM , then, from the corollary 1, we can clearly

solve the RSA instance since gcd(e, 2(M* −M)) = 1 with overwhelming probability (because e is

a large prime number unknown to PPT adversary A). From lemma 5.1, B uses the extended

Euclidian algorithm to efficiently compute integers a and b such that a.e+b.2(M*-M)=1 and

outputs

y1/e

=yaz

b. (5.35)

From the above, we can see that if any file block is corrupted by the adversary, then B can

construct a knowledge extractor ε to extract file blocks in a probabilistic polynomial time based

on knowledge of multiple challenge-responses. If knowledge extractor cannot extract the file

blocks, we used extend Euclidian algorithm to efficiently compute the file blocks.

In conclusion, under the KEA1-r and RSA assumption, the RSA-DPAP scheme guarantees

the data Integrity in random oracle against adversary model.

Detection Probability

In this section, we analyze the detection probability of it being corrupted blocks and show

that RSA-DPAP scheme required to operate on selected (random) blocks instead of all which

can greatly reduce the computational overhead on the verifier and server, while maintaining

detection of data corruptions with a high probability (99%).

The detection probability P of corrupted blocks is an important parameter to guarantee that

these blocks can be detected in time. Assume the TPA modifies the z blocks out of the n block

file. The probability of corrupted data blocks is

r

rl

zrlr

l

zl

rl

zrl

l

zl

l

zl

XP

XPP

xP

x

)(1)(1

11

1

1......

1

1.1

)0(1

}1{

(5.36)

118

Let r be the number of queried blocks for a challenge e in the protocol.

Comparisons with Existing Schemes

Here, we compare the detection probability of RSA-DPAP scheme with existing probability

verification schemes using pseudorandom sequence [13,16,148,165, 169,] and shown results in

Table 5.3. From the Table 5.3, we can see that RSA-DPAP scheme using sobol sequence detects

the data corruptions efficiently than existing schemes using pseudorandom sequence.

Table 5.3: Detection probability of 1%l data corruption out of 300000 blocks

Detection Probability

Number of samples as percentage of total samples

RSA-DPAP using

Sobol Sequence

Existing Schemes

Pseudorandom Sequence

[13, 165,169,]

0.50 10%l 15%l

0.6 20%l 25%l

0.7 24%l 34%l

0.8 28%l 40%l

0.9 32%l 48%l

0.95 35%l 55%l

0.99 38%l 65%l

5.3.2. Performance Analysis of RSA-DPAP

In this section, we analyze the performance of RSA-DPAP scheme, experimental results and

compare the results with existing RSA-based scheme [13], which includes storage,

Communication, and Computation Costs.

a) Storage Cost

We derive the storage cost required by the Client, TPA and CSP as follows:

Client Side: The Client needs to store the only public key and secrete key. The storage cost

for them is:

119

2|N|+|e|+|d| bits. (5.37)

Server Side: the server needs to be store the file. So its storage cost is m bits.

TPA or Verifier Side: the verifier needs be to store tags and public key. The tag set is a

relatively smaller than the original file, so storage cost of tags is O (n) at verifier side, which is

same as [13].

b) Computation Cost

We analyze the computation cost of the Client, CSP and TPA as follows:

Client Side: Here, we analyze cost for computing metadata during the setup phase, the

Client computes the metadata for each of the file block. From the Euler Theorem [78], we all

know that gcd(g, N)=1 i.e. we should have 1mod)( Ng N

. So, the Client can

compute )(mod Nmi before computing Ng immod . As modulo operations are more efficient

than modular exponentiations, then the total computation cost of the Client is upper bounded by

⌈|m|/l⌉Texp(|N|, N), (5.38)

where Texp(len, num) is the time for computing a modular exponentiation with a len-bit long

exponent modular num.

In addition, the computation cost for block insertion or block modification is just one

modular exponentiation, which is Texp(|N|,N).

CSP Side: During the verification phase, the server needs to generate n-Sobolrandom b-bit

integers aj, then it compute j

c

i

s

sj

jmar

1

NgRji

cs

sjjma

s mod1

The computation of each jij ma corresponding to the product of two integers being b and l bits

long respectively. The computation cost of jijma is upper bounded by (b − 1) additions of (b +

l)-bit integers. Once the values of jijma have been computed. Then, r is obtained by computing

(n − 1) additions of (b + l) bit integers, the computation cost of this operation is upper bounded

by (n-1) additions of (|n|+b+l) bits.

In summary, the cost of computing R is upper bounded by the cost of generating n

Sobolrandom b-bit integers plus the cost of computing one exponentiation of a number in Zn to

and

120

an (|n|+b+l )-bit exponent plus the cost of n(t-1) additions of (t+1) bit integers plus the cost of

(n-1) additions of (|n|+b+l)-bit integers. Since Tadd(b+1)< Tadd(|n|+b+1) and n= ⌈|m|/l⌉, so total

computation cost of server is upper bounded by

⌈|m|/l⌉ · Tsrng(b) + Texp(|⌈|m|/l⌉| + b + l, N) (5.39) +b⌈|m|/l⌉ ⌉Tadd(|⌈|m|/l⌉| + b + l).

TPA Side: During the verification phase, the TPA needs to generate three random numbers

⟨j, kSRF, gs⟩, Then, compute SRPkqs (q) and gs = g

s mod N, whose cost is 3 Sobolrandom

number generations plus Texp(|N|,N). plus (n-1) multiplications of (|n|+b+N) bits. Then during

the Algorithm 5.5, the verifier computes ],[},{ 1 cj ssja , P and R' respectively. The

Computation cost of R' is similar to R that on the server side. Here, we are replacing l-bit

operations by N-bit operations. Hence, the computation cost of verifier is upper bounded by:

3+ ⌈|m|/l⌉) Tsrng(b)+ b+Texp(|N|,N) + b⌈|m|/l⌉ Tadd(⌈|m|/l⌉+b+|N|). (5.40)

c) Communication Cost

The communication cost consists of the ―random samples‖ challenge sent by the verifier to

the server, which consists of |N|+k and the response sent by the server to the verifier, which

consists of bit-length |N|. So, total communication cost is:

k+|2N| bits. (5.41)

5.3.3. Experimental Results of RAS-DPAP

We implemented the RSA-DPAP on desktop with core2 duo 2.00GHZ CPU and 4GB

RAM and 320GB SATA Hard Drive. All programs written in C++ program with help of

Sobol_Data Set library [27].

Here, we measure the computation costs of the verifier and server for same file with

different block lengths as well as same block length and different file sizes. Then, compare the

RSA-DPAP results with previous scheme [13].

121

For example, we use the file F with 4MB , choose the file length of N to be 1024 bits and

also choose k=128 and b=128. In Table 5.4 and Table 5.5, we measured the computation cost of

the verifier and server respectively by using existing scheme [13] and RSA-DPAP scheme.

Similarly in Table 5.6 and 5.7, we measured the computation cost of the verifier and server when

different file lengths and fixed block lengths are used. Compared to previous scheme [13], the

RSA-DPAP scheme takes very less time for computation at the verifier and server side in both

cases, because Sobol sequence takes very less time to generate random numbers than

pseudorandom generator. From Table 5.4, 5.5, 5.6 & 5.7, we can see that the computation cost of

RSA-DPAP at verifier and server sides is faster than existing scheme [13].

Table 5.4: Computation Cost at Verifier side with fixed file size 4MB and

different block lengths

l(bits) Verifier side in

Existing scheme[13]

Verifier Side using

RSA-DPAP

65,536(216) 653.37 ms 563.26 ms

131,072(217) 328.81ms 274.43 ms

262,144((218) 173.62 ms 128.62 ms

524,288(219) 95.46 ms 60.09 ms

104,576(220) 48.64 ms 23.13 ms

Table 5.5: Computation Cost at Server side with fixed file size 4MB and

different block length

l(bits) Server Side in

Existing scheme[13]

Server Side in

RSA-DPAP

65,536(216) 591.1 ms 514.11 ms

131,072(217) 1161.1 ms 1025.43 ms

262,144((218) 2304.39 ms 2123.21 ms

524,288(219) 4558.67 ms 4336.21 ms

104,576(220) 9152.9 ms 8890.91 ms

122

Next, we have measured the computation cost of the verifier and server with different file

sizes and fixed block lengths.

Table 5.6: Computation Cost at Verifier side with different file sizes and fixed block

length.

File Size l(bits) Verifier side in

Existing scheme 13] Verified side in RSA-DPAP

1MB 65,536(216) 176.24 ms 148.26 ms

2MB 65,536(216) 332.55 ms 274.05 ms

4MB 65,536(216) 653.37 ms 576.25 ms

8MB 65,536(216) 1281.9 ms 1083.9 ms

Table 5.7: Computation Cost at Server side with different file sizes and fixed block

length

File Size l(bits) Server Side in Existing

scheme [13] Server Side in RSA-DPAP

1MB 65,536(216) 568.16 ms 488.16 ms

2MB 65,536(216) 574.23 ms 501.23 ms

4MB 65,536(216) 591.1 ms 522.11 ms

8MB 65,536(216) 618.04 ms 552.17 ms

Pre-Processing Cost: here, we measure the Clients pre-processing cost during the

setup phase for metadata generation, which is shown in Table 5.8.

Table 5.8: Client pre-processing with Different Block Size for 4MB File

Block length Pre-Processing Cost

64KB 4,578

128KB 2,318

256KB 1,245

512KB 589

1024KB 275

123

The RSA-based dynamic audit protocol achieved the Availability and Integrity of data

stored in Cloud with the support of public verifiability and efficient dynamic data operations.

However, it lacks in addressing an efficient Confidentiality issue, which is one of important

security aspect of data storage for some applications. Because, if encrypt the data using RSA

key, it increase the processor overhead due to the large size of RSA key and mainly it is not

suitable for resource constrained devices.

To overcome this problem, we propose an ECC-based protocol, which will be explained in

the next section.

5.4. ECC-based Dynamic Public Audit Protocol (ECC-DPAP)

To ensure the Confidentiality, Integrity and Availability of data efficiently in the cloud, we

propose an ECC-based dynamic public audit protocol. This protocol is designed under the

Elliptic Curve cryptography [88,127, 130, 173] construction instead of RSA-assumption, which

is used in above protocol given in section 5.3. This protocol can offer same levels of security

with small keys comparable to RSA-DPAP. It is mainly designed for devices with limited

computing power and/or memory, such as smartcards, mobile devices and PDAs.

Like RSA-DPAP, this protocol also consists of three phases, namely

1) Setup phase 2) Verification phase3) Dynamic Data Operations and Verification phase

5.5.1. Setup Phase: ECC-DPAP

The Setup phase consists of four methods as shown in Fig. 5.2: a) Encoding

b) KeyGeneration c) Encryption d) MetadataGeneration.

The detailed descriptions of these four methods are explained in the following sections:

We use the same algorithm given in Fig. 4.6 for the encoding using CRS or tornado code

depending on application in ECC-DPAP.

b) KeyGeneration: ECC-DPAP

In this algorithm, the Client generates private key and public key pair using algorithm 5.9

based on elliptic curve cryptography, it takes k as input and generates private key and public key

124

pair as output as follows: the given security parameter k (k>512), Client chooses two large

primes p and q of size k such that p≡q≡ 2 (mod 3). Then compute

n=pq (5.42)

and

Nn=lcm(p+1,q+1). (5.43)

where Nn is a order of elliptic curve over the ring Zn denoted by En (0, b), and b is a randomly

chosen integer such that gcd(b, n)=1 and compute P is a generator of En(0, b). It outputs public

key PK= {b, n, p} and private key PR={ Nn)}.

Algorithm 5.9: KeyGen : ECC-DPAP 1. Procedure: KeyGen(k) ←{ PK,PR} 2. Take security parameter k (k>512) 3. Choose two random primes p an q of size k: p≡q≡ 2 (mod 3) 4. Compute n=pq 5. Compute Nn = lcm(p+1, q+1) 6. Generate random integer b<n, gcd(b, n)=1 7. Compute P, is a generator of En(0,b) 8. Private key PR={ Nn } 9. Public key PK={n, b, P} 10. end procedure

c) Encryption: ECC-DPAP

To ensure the Confidentiality of data, the Client encrypts the each data block mi in the file F

using algorithm 5.10, it takes mi, keyed Sobol Ranodom Function(SRF) and secrete random

parameter s as inputs and produce m'i as output as follows:

niin mmmmF 121 }{},...,{ (5.44)

)(sfmmF kii (5.45)

where s is random of size l.

Algorithm 5.10: Encryption : ECC-DPAP

1. Procedure : Encryption(mi , s)←m'i

2. for 1 to n

3. Compute )(' sfmm kii

4. end for

5. end procedure

125

d) MetadataGeneration: ECC- DPAP

After encrypting the data, the Client computes the metadata using ECC-based HVTs over

encrypted data to verify the Integrity of data using algorithm 5.11, which takes m'i, public key

and private key as inputs and produce metadata Ti as output:

Ti ← m'i P(mod Nn)) (5.46)

where Pε En(0, b)

Algorithm 5.11: MetadataGen: ECC-DPAP 1. Procedure: MetadataGen(m'i ,n, b, P) ←Ti

2. for 1 to n

3. Compute Ti ← m'i P(mod Nn))

4. end for

5. end procedure

After computation of metadata, the Client sends metadata, public key to the TPA for later

verification and sends file F' to cloud servers for storage. Then TPA stores public key and

metadata and the CSP stores the encrypted data file. The processes of setup phase is described

in Fig.5.6.

Client TPA CSP 1. Client generate a key pair

PK= {b, n, p} and PR={ Nn)}.

2. Encrypts )(' sfmm kii

3. Client computes metadata by running MetadataGen algorithm Ti ← m'i P(mod Nn))

4.Sends F=(m1,m2,…mn) to server 5. The server stores the file F in

cloud

6.Send pk, Ti to TPA

7.The TPA stores Ti and pk for later processing

8. Client stores the private key and deletes file F and metadata Ti from locally

Fig. 5.6 Setup Phase: ECC-DPAP

126

5.5.2. Verification Phase: ECC-DPAP

Like RSA-based protocol, this protocol also consists of three algorithms: a) Challenge, b)

Response c) CheckIntegrity as shown Fig. 5.2.

a) Challenge: ECC-DPAP

The verifier creates a challenge by running algorithm 5.12, it takes kSRF,j, and Q as input

and return chal as output as follows: the TPA chooses a random keys kSRF and kSRP using Sobol

sequence and computes random indices 1≤ij≤n (j= 1,….,c) of the set[1,n], where

)(cc

SRPk (5.47)

which prevents the server from anticipating which blocks will be queried in each challenge. The

TPA also generates a fresh random value r to guarantee that the server does not reuse any values

from the previous challenge and computes

Q=rP. (5.48)

Then, TPA creates the challenge chal={ kSRF, j, Q} , and sends to the server.

Algorithm 5.12: Challenge : ECC-DPAP 1. Procedure: Challenge(kSRF,j,Q) ← chal 2. Generates a random keys kSRF, kSRP and fresh random value using Sobol Sequence. 3. Compute

SRPkc (c)

4. Compute Q=rPε En(0, b) 5. Create challenge chal={ kSRF, j, Q} 6. end procedure

b) Response: ECC-DPAP

Upon receiving a challenge from the verifier, each server computes a response as Integrity

proof using algorithm 5.13, it takes encrypted data m'i, challenge chal as inputs and produce

response R as output as follows: first, it generates random numbers using Sobol random Function

(SRF) i.e.

)( jfaSRFkj

(5.49)

Then compute

c

j

ij jmab

1

(5.50)

127

where 1≤ ij≤n

Later, computes a response

nbQR mod (5.51)

)mod(

mod

mod

1

1

1

nPmar

nrPma

nQma

c

j

ij

c

j

ij

c

j

ij

j

j

j

(5.52)

Algorithm 5.13: Response: ECC-DPAP 1. Procedure: ProofGen(m'i , kSRF, Q)←R 2. Generates a n random numbers using kSRF 3. for 1 to n 4. Generate )( jfa

SRFkj

5. end for

6. compute

c

j

ij jmab

1

7. compute R=bQ mod n 8. end procedure

c) CheckIntegrity : ECC-DPAP

After receiving a response from the server, the verifier checks the Integrity using

algorithm 5.14, it takes public key pk, challenge query chal, and proof R as inputs and return

output as 1 if the Integrity of file is verified as successfully or 0 as follows: the verifier re-

generates random numbers using Sobol Random function i.e.

)( jfaSRFkj

Then compute S= nTac

j

ij jmod

1

(5.53)

nrSR mod' (5.54)

Now, verifier checks whether

R'=R, (5.55)

if response is valid, then it returns 1 otherwise 0.

128

Algorithm 5.14: CheckIntegrity: ECC-DPAP 1. Procedure: CheckProof(T'i , r, kSRF, n)←R' 2. Generates a n random numbers using key kSRF 3. for 1 to n 4. Generate )( jfa

SRFkj

5. end for

6. compute S= nTac

j

ij jmod

1

7. compute nrSR mod'

8. verify if (R'=R) 9. return true 10. else 11. return false 12. end if 13. end procedure

The process of verification phase is given in Fig 5.7.

TPA CSP 1. TPA genates a challenge

chal={ kSRF, j, Q} and sends to the CSP.

Challenge request chal

2. Generates )( jfaSRFkj where i=[s1,sc]

3. Computes

c

j

ij jmab

1

.

Computes nbQR mod

NbQR mod

Integrity Proof R

4. Re-generate SRFkfa j (j ) using kSRF

5. Computes nTaS

c

j

ij jmod

1

6. Computes

nrSR mod'

7. Verify if R'=R returns ‘1’ otherwise ‘0’

Fig. 5.7 Verification Phase: ECC-DPAP

129

5.5.3. Dynamic Data Operations and Verification Phase: ECC-DPAP

The dynamic data operations of this protocol are same as RSA-DPAP scheme in section

5.3.3 except encrypt the updated block in prepare update algorithm.

5.6. Analysis of ECC-DPAP

Here, we analyze the security, performance and experimental results of ECC-DPAP

5.6.1. Security Analysis of ECC-DPAP

In this section, we present the formal security analysis of the ECC-DPAP scheme. That

means Confidentiality, Integrity and Availability of data stored in the cloud. The Availability

of data analysis is same as section 4.4.1.2.

a) Integrity

To ensure the Integrity, we need three properties: Completeness, Soundness and Probability

Detection. Here, we define these terms as follows: for completeness, soundness [127] and

Probability Detection [126]

Completeness: After receiving a challenge from the verifier, if server honestly computes a

correct Integrity proof, the verifier always accepts the proof as valid.

Soundness: After receiving a challenge from the verifier, the server dishonestly computes the

Integrity proof by missing some data bits, the verifier accepts with negligible probability.

Probability Detection: After receiving a response from the server, the verifier check whether

response is valid or not? If it is not valid, then the verifier detects the corruptions with high

probability.

Theorem 5.2. The ECC-DPAP is complete

Proof: Here, we are proving this theorem according to the definition of sound and

commutative property of point multiplication in an elliptic curve [127].

we have RR '

130

c

j

ij

ni

c

j

j

i

c

j

j

nPma

nNPma

nTaS

nrSR

j

j

j

1

1

1

mod

mod)mod(

mod

mod'

(5.56)

R

nPmar

nPmar

nrSR

c

j

ij

i

c

j

j

j

j

)mod(

)mod((

mod'

1

1

From the equation (5.55), the protocol is complete or valid. Then the verifier is

―probabilistically‖ assured that server still holds data safely. In reality, verifier only verifies

that server holds the j [1, c] selective blocks where j is chosen randomly.

Theorem 5.3: The ECC-DPAP is sound

Proof: In this proof, we show that ECC-DPAP is sound against dishonest server based on

previous transactions and pre-computed metadata. There are four possibilities that the server can

compute the Integrity proof without storing the Clients‘ data.

1) The server guessed or use pre-computed value. However, guessing occurs with negligible

probability and pre-computing the correct response is not possible because each time the verifier

asks the server with a fresh challenge.

2) Other option is to cheat the Client, the server replayed the previous response. In this case, the

server would have to find r from challenge chal to compute the correct proof. since r is chosen

randomly, finding r is hard based on ELDL problem.

3) Another option for the server to cheat Client is: he has an algorithm to compute m'i mod Nn

with inputs instead of storing m'i[1≤i≤n]. But this option is not possible, because, the server

cannot compute Nn based on the hardness of solving the order of elliptic curve En(0, b) as we

discussed above.

(5.57)

(5.58)

131

4) Last option for server is, if the server does not store the data {m'i} and it may try to collude

with the other servers for storing the same data. However, this option is not feasible, since data

stored at each server is securely encrypted using Sobol Random Function (SRF). The f is a keyed

one-way function and s is a secrete parameter, so, no one except the Client can retrieve the

original data mi from m'i.

All these options lead to contradiction; so the server cannot compute response without

storing the data. Hence, ECC-DPAP protocol is complete.

Detection probability:

The detection probability of ECC-DPAP is same as the RSA-DPAP, which was discussed

in section 5.4.1a.

b) Confidentiality

Now, we analyze the Confidentiality of ECC-DPAP: The stored data in cloud cannot be

leaked to an malicious attackers (servers and TPA). In this analysis, we depend on the hardness

of the Elliptive Curve Diffie-Hellman (ECHP) and Elliptive Curve Discrete Logarithm (ECDL)

problems.

Theorem 5.4: The ECC-DPAP is confidential against data leakage to attacker.

We prove this theorem under different attacks:

1) The secret parameter s cannot be derived by a malicious Client eavesdropping on the

communication link between the Client and server because of Elliptive Curve Diffie-

Hellman (ECDH) problem. The public parameter {b, n, P} cannot help the adversary to

infer or calculate any useful information that can reveal the shared key between the Client

and server.

2) Suppose, If the malicious server wants to access the data from the encrypted file F'=mi'.

But it is not possible, because in order to access the encrypted data, he should need a secrete

parameter, this secrete key chosen by Client randomly. If server tries to get the secret key by

using different combinations of public parameters but fail to do so due to the ECDL problem.

Hence, the malicious server cannot learn anything from F'.

132

3) The TPA has Ti ← m'i P(mod Nn). If he tries to access data content from metadata, the

Client computes metadata over encrypted the data using secrete key. However, it is not

possible because the secrete parameter chosen by the Client from random. So there is no

chance to TPA get secrete parameter using public key and metadata. Hence, The TPA cannot

learn anything from metadata Ti.

Therefore on the basis of ECDH and ECDL problems, ECC-DPAP scheme is confidential

against data leakage.

5.6.2. Performance Analysis of ECC-DPAP

In this section, we analyze the performance of ECC-DPAP in terms of storage,

communication and computation complexity.

a) Storage cost

Here, we detail the storage cost required by the Client, TPA and Server.

Client Side: The user needs to store the only secrete parameter. The storage cost for that is

O (1).

Server Side: the server needs to be store the complete file, the cost for storage file is O (n)

bits.

TPA side: the verifier needs to store metadata and public key. The metadata is a relatively

smaller than original file, so storage cost for metadata is O (1).

b) Communication Cost

Here, we consider the communication cost between the server and verifier during

verification phase. The challenge sent by the verifier to the server, which consists of O(1) and the

response(it is a small size compare to original file) sent by server to the verifier, which consists

of O(1). Thus, total communication cost is O (1).

c) Computation Cost

We analyze the computation cost of the Client, verifier and server as follows:

133

Client: during the setup phase, the Client generates a private key and public key whose cost is

O(1) . Then, to encrypt a file, the Client needs to perform integer addition, its cost is O(n).

Finally, computes the metadata by performing n-bit point multiplications whose cost is O(1).

Hence, total computation cost of the Client is: O (1).

TPA: During the verification phase, the TPA or verifier needs to generate three random numbers

⟨kSRF,j, r⟩, then compute SRPkc (c) and Q = rP, whose cost is O(1). Again, after receiving the

response, the verifier re-generates {aj} j=[1,c], the computation cost of each jijma corresponds

to the sum of point multiplication of two bits. Finally, the verifier computes R', the cost of R' is

a two point multiplications plus sum of 2 bit integer plus generating random numbers cost, which

is O(1) respectively. Hence, the total computation cost at verifier side is O(1).

Server: During the verification phase, the server needs to generate n-Sobolrandom b-bit integers

ai , then it computes ji

c

j

jmab 1

R nPmarji

n

i

j mod'1

. The computation of each jijma

corresponds to the sum of point multiplication of two bits. The computation cost of jijma is

O(1). Next, the server computes a proof, which consists of point multiplications in response

algorithm 5.13, its cost is O (1). The total computation cost of server for generating Integrity

proof (response) is O(1). In Table 5.9, we summarized the storage, communication and

computation costs.

Table 5.9: Summary of Storage, Communication and Computation cost of ECC-DPAP

Storage Cost Communication Cost

Computation Cost

Verifier

Server

Server

Client

Verifier Verifier Server

O(1) O(n) O(1) O(1) O(1) O(1) O(1)

and

134

5.6.3.Experimental Results of ECC-DPAP

In this section, we present the experimental results of ECC-DPAP and compare the

results with RSA-DPAP. All experiments conducted using C++ on system with dual core 2-GHZ

processor and 4GB RAM running Windows 2007. In ECC-DPAP implementation, we use

MIRACL library version 5.4.2 to achieve better security work on elliptic curve with 160-bit

group order instead of RSA on 1024 bits. Here, we are measuring total time for computation cost

of the verifier and server using ECC and RSA respectively.

100

RSA

ECCRSASpeedup (5.59)

Then, we compare computation cost of ECC-DPAP scheme with RSA-DPAP scheme,

which includes the verifier, server and Client computation costs and presented results in Table

5.10, 5.11 &5.12. These tables shows that the performance cost of ECC-DPAP is efficient than

RSA –DPAP.

Table 5.10: Computation Cost at Verifier using RSA-DPAP and ECC-DPAP schemes

File Size Verifier side using RSA-DPAP Verifier Side using ECC-DPAP Speedup

10MB 424.37 ms 316.26 ms 25%

20MB 482.81 ms 342.43 ms 29%

30MB 561.62 ms 376.03 ms 32%

40MB 641.46 ms 415.09 ms 35%

50MB 743.64 ms 465.13 ms 38%

Table 5.11: Computation Cost at Server with RSA –DPAP and ECC-DPAP schemes

l(bits) Server Side with RSA-DPAP Server Side

with ECC-DPAP

Speedup (%)

10MB 388.01 ms 275.11 ms 29%

20MB 447.62 ms 312.43 ms 30%

30MB 508.39 ms 348.21 ms 31%

40MB 562.67 ms 381.21 ms 32%

50MB 625.16 ms 418.76 ms 33%

135

Table 5.12: Metadata Computation Cost at Client with RSA-DPAP and ECC-DPAP schemes

l(bits) Client with RSA-DPAP Client Side

with ECC-DPAP

SpeedUp(%)

10MB 244.11 ms 183.06 ms 25%

20MB 296.41 ms 218.32 ms 26%

30MB 352.53 ms 253.38 ms 28%

40MB 403.17 ms 289.63 ms 29%

50MB 467.26 ms 323.92 ms 30%

5.7. Summary

In this chapter, we presented two Dynamic Public Verification Protocols that leverages

public key cryptography techniques. We showed that Integrity of data with public verification

and efficient dynamic data operations in RSA-DPAP and ECC-DPAP schemes. In RSA-DPAP,

we used RSA-Public key cryptography. In ECC-DPAP, we used Elliptic Curve Cryptography

(ECC).

We compared ECC-DPAP with RSA-DPAP, Most of the schemes that use RSA based

verification processes but the key length for secure RSA is increased over recent years and this

put a heavier processing burden on applications using RSA. To avoid this problem, we proposed

an ECC-DPAP. The principal of ECC compared to RSA is that it appear to offer equal security

for a far smaller key size, thereby it reduced the computation overhead. Finally, the ECC-DPAP

is private against unauthorized data leakage because, we are encrypting the data before storing in

cloud.

The ECC-DPAP can offer same levels of security with small keys comparable to RSA-

DPAP. It is mainly designed for devices with limited computing power and/or memory, such as

smartcards, mobile devices and PDAs. However, it is introducing the non-trivial key

management problems to the Clients. In order to protect encryption keys for Confidentiality of

data, the Clients need to encrypt keys again, which change the problem rather than solve it.

To avoid key management problems for the Clients, we propose a Public verifiable

Dynamic Secret Sharing protocol, which will be explained in the next Chapter.