<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE article  PUBLIC "-//NLM//DTD Journal Publishing DTD v3.0 20080202//EN" "http://dtd.nlm.nih.gov/publishing/3.0/journalpublishing3.dtd"><article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" dtd-version="3.0" xml:lang="en" article-type="research article"><front><journal-meta><journal-id journal-id-type="publisher-id">IJCNS</journal-id><journal-title-group><journal-title>International Journal of Communications, Network and System Sciences</journal-title></journal-title-group><issn pub-type="epub">1913-3715</issn><publisher><publisher-name>Scientific Research Publishing</publisher-name></publisher></journal-meta><article-meta><article-id pub-id-type="doi">10.4236/ijcns.2017.105B027</article-id><article-id pub-id-type="publisher-id">IJCNS-76621</article-id><article-categories><subj-group subj-group-type="heading"><subject>Articles</subject></subj-group><subj-group subj-group-type="Discipline-v2"><subject>Computer Science&amp;Communications</subject></subj-group></article-categories><title-group><article-title>
 
 
  Data Integrity Checking Protocol with Data Dynamics in Cloud Computing
 
</article-title></title-group><contrib-group><contrib contrib-type="author" xlink:type="simple"><name name-style="western"><surname>Junjie</surname><given-names>Feng</given-names></name><xref ref-type="aff" rid="aff1"><sup>1</sup></xref></contrib><contrib contrib-type="author" xlink:type="simple"><name name-style="western"><surname>Shigong</surname><given-names>Long</given-names></name><xref ref-type="aff" rid="aff2"><sup>2</sup></xref></contrib></contrib-group><aff id="aff2"><addr-line>College of Computer Science and Technology, Guizhou University, Guiyang, China</addr-line></aff><aff id="aff1"><addr-line>College of Science, Guizhou University, Guiyang, China</addr-line></aff><pub-date pub-type="epub"><day>26</day><month>05</month><year>2017</year></pub-date><volume>10</volume><issue>05</issue><fpage>274</fpage><lpage>282</lpage><history><date date-type="received"><day>May</day>	<month>10,</month>	<year>2017</year></date><date date-type="rev-recd"><day>Accepted:</day>	<month>May</month>	<year>23,</year>	</date><date date-type="accepted"><day>May</day>	<month>26,</month>	<year>2017</year></date></history><permissions><copyright-statement>&#169; Copyright  2014 by authors and Scientific Research Publishing Inc. </copyright-statement><copyright-year>2014</copyright-year><license><license-p>This work is licensed under the Creative Commons Attribution International License (CC BY). http://creativecommons.org/licenses/by/4.0/</license-p></license></permissions><abstract><p>
 
 
   
   We introduce a model for provable data possession (PDP) which allows a client that has stored data at an untrusted server to verify that the server possesses the original data without retrieving it. In a previous work, Ateniese et al. proposed a remote data integrity checking protocol that supports data partial dynamics. In this paper, we present a new remote data possession checking protocol which allows an unlimited number of file integrity verifications and efficiently supports dynamic operations, such as data modification, deletion, insertion and append. The proposed protocol supports public verifiability. In addition, the proposed protocol does not leak any private information to third-party verifiers. Through a specific analysis, we show the correctness and security of the protocol. After that, we demonstrate the proposed protocol has a good performance. 
  
 
</p></abstract><kwd-group><kwd>Provable Data Possession (PDP)</kwd><kwd> Cloud Storage</kwd><kwd> Data Dynamics</kwd><kwd> Public  Verifiability</kwd><kwd> Data Integrity</kwd></kwd-group></article-meta></front><body><sec id="s1"><title>1. Introduction</title><p>Recently, many works focus on providing remote data integrity checking protocols. Because storing data in the cloud has become a trend and an increasing number of clients store their important data in remote servers in the cloud, without leaving a copy in their local computers. Sometimes the data stored in the cloud is so important that the clients must ensure it is not lost or corrupted. Using a remote data integrity checking protocol, the client might be able to periodically verify that whether the data stored on the server side is complete. Any corruption will be noticed by the data owner who will be able to take immediate action.</p><p>Remote data integrity checking protocols have been proposed in the last few years and two recent results [<xref ref-type="bibr" rid="scirp.76621-ref1">1</xref>] Provable Data Possession (PDP) [<xref ref-type="bibr" rid="scirp.76621-ref2">2</xref>]-[<xref ref-type="bibr" rid="scirp.76621-ref14">14</xref>] and Proofs of Retrievability (POR) [<xref ref-type="bibr" rid="scirp.76621-ref15">15</xref>] have highlighted the importance of the problem and suggested two very different approaches. Ateniese et al. [<xref ref-type="bibr" rid="scirp.76621-ref2">2</xref>] first defined the notion of PDP, which allows a client to verify the integrity of its data stored at an un-trusted server without retrieving the entire file. Their scheme is designed for static data and used public key-based homomorphic tags for auditing the data file. Nevertheless, the pre-computation of the tags imposes heavy computation overhead that can be expensive for entire file. Subsequently, Ateniese et al. [<xref ref-type="bibr" rid="scirp.76621-ref3">3</xref>] constructed scalable and efficient schemes using symmetric keys in order to improve the efficiency of verification. This results in lower overhead than their previous scheme. The scheme partially supports dynamic data operations; however, it is not publicly verifiable and is limited in number of verification requests. Thereafter, several works were done following the models given in [<xref ref-type="bibr" rid="scirp.76621-ref2">2</xref>] [<xref ref-type="bibr" rid="scirp.76621-ref3">3</xref>]. Wang et al. [<xref ref-type="bibr" rid="scirp.76621-ref4">4</xref>] combined a BLS-based homomorphic authenticator with a Merkle hash tree to achieve a public auditing protocol with fully dynamic data. Recently, Mao Jian et al. [<xref ref-type="bibr" rid="scirp.76621-ref5">5</xref>] proposed the detection data of dynamic cloud using Merkle tree, the results show that this method is very effective. Erway et al. [<xref ref-type="bibr" rid="scirp.76621-ref6">6</xref>] proposed a fully dynamic PDP scheme based on rank-based authenticated dictionary. Unfortunately, their system is very inefficient. Hao Zhuo’s protocols [<xref ref-type="bibr" rid="scirp.76621-ref7">7</xref>] support data dynamics and public verifiability, but the calculation of this protocol and the number of blocks have a direct relationship, the amount of computation is still relatively large. After that Wei Xu et al. [<xref ref-type="bibr" rid="scirp.76621-ref8">8</xref>] proposed a remote storage integrity checking protocol based on homomorphic hash function, but the disadvantage of this protocol is losing feature of public verifiability. Zhu et al. [<xref ref-type="bibr" rid="scirp.76621-ref9">9</xref>] created a dynamic audit service based on fragment structure, random sampling and index-hash table that supports timely anomaly detection. Recently, Chun- ming Tang et al. [<xref ref-type="bibr" rid="scirp.76621-ref10">10</xref>] propose a new publicly verifiable method based on linearly homomorphic cryptography.</p><p>As a summary of the outstanding protocols: a protocol which satisfies the following requirements ought to be called a perfect protocol: [<xref ref-type="bibr" rid="scirp.76621-ref11">11</xref>] [<xref ref-type="bibr" rid="scirp.76621-ref12">12</xref>]</p><p>1) The amount of communication, Storage and computation required by the protocol should be low.</p><p>2) It ought to be possible to run the verification an unlimited number of times.</p><p>3) It supports dynamic operations include modification, deletion, insertion and append.</p><p>4) It supports privacy protection.</p><p>5) It supports public verifiability.</p><p>6) The changed data can be recovered.</p><p>7) It is suitable for large data integrity detection.</p><p>Current protocols can not meet all the above requirements. In this paper, the proposed protocol satisfies the above mentioned (1, 2, 3, 4, 5, 7). We have the following main contributions:</p><p>1) We propose a remote data integrity checking protocol for cloud storage, and the proposed protocol inherits the support of data dynamics from [<xref ref-type="bibr" rid="scirp.76621-ref3">3</xref>].</p><p>2) We give a security analysis of the proposed protocol which shows that it is secure against the un-trusted server</p><p>3) We have theoretically examined the performance and the results demonstrate that our protocol is efficient.</p><p>The rest of this paper is organized as follows: The new data possession checking protocol is described in Section2. Security analysis of the proposed protocol is presented in Section3. In section 4 we describe the support of data dynamics of the proposed protocol. Analysis of the proposed protocol is presented in Section5. Section 6 is a conclusion.</p></sec><sec id="s2"><title>2. The New Data Integrity Checking Protocol</title><p>We consider a cloud storage system in which there is a client and an un-trusted server. The client stores her data in the server without keeping a local copy. Hence, it is of critical importance that the client should be able to verify the integrity of the data stored in the remote un-trusted server. If the server modifies any part of the client’s data, the client should be able to detect it; furthermore, any third-party verifier should also be able to detect it. In case a third-party verifier verifies the integrity of the client’s data, the data should be kept private against the third-party verifier.</p><p>In this scheme, we add the agreement stage between the client and the server, thus the use of probability select detection data reduces the computation both of the server and the verifier. The proposed protocol consists of five phases: Setup, Giggen, Agreement, Challenge and Verification.</p><p>Notice:</p><p><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x2.png" xlink:type="simple"/></inline-formula>―cryptographic hash function. In practice, we use standard hash functions.</p><p><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x3.png" xlink:type="simple"/></inline-formula>―pseudo-random function.</p><p><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x4.png" xlink:type="simple"/></inline-formula>―the probability that can ensure the detection of the changed data blocks.</p><p>t―assume that the number of data blocks that have been changed.</p><p><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x5.png" xlink:type="simple"/></inline-formula>―random number.</p><p>Setup: Firstly, given the security parameter k, client run the key generation algorithm and returns a pair of matching public key pk and the secret key sk. pk is public to everyone, while sk is kept secret by the client. Then, the client selects random number generation function <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x6.png" xlink:type="simple"/></inline-formula> and a authentication index r. The m denote the file that will be stored in the un-trusted server, which is divided into n blocks of equal lengths: <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x7.png" xlink:type="simple"/></inline-formula></p><p>SigGen: The client computes the verification tag for each block: <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x8.png" xlink:type="simple"/></inline-formula>, <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x9.png" xlink:type="simple"/></inline-formula>, then using the secret key <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x10.png" xlink:type="simple"/></inline-formula> to encrypt the tag<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x11.png" xlink:type="simple"/></inline-formula>, <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x13.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x12.png" xlink:type="simple"/></inline-formula>represents a collection of all tags and sends <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x14.png" xlink:type="simple"/></inline-formula> to the server.</p><p>Agreement: The client sends the probability information of the data blocks to be detected to the verifier:<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x15.png" xlink:type="simple"/></inline-formula>. The verifier receives the information and then uses the public key of the client to decrypt information and calculate to be detected for a data block c after decryption, then sends <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x16.png" xlink:type="simple"/></inline-formula> to the client. The client received the message and decried it, so he can ensure that the verifier had received the message from him.</p><p>Challenge: The verifier selects c data blocks to be detected, and at the same time, the random challenge nonce <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x17.png" xlink:type="simple"/></inline-formula> is calculated for each data block. Then the verifier sends <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x18.png" xlink:type="simple"/></inline-formula> to the server.</p><p>Verification: Having received the message from verifier, server computes <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x19.png" xlink:type="simple"/></inline-formula> and</p><disp-formula id="scirp.76621-formula266"><graphic  xlink:href="http://html.scirp.org/file/76621x20.png"  xlink:type="simple"/></disp-formula><p>The server then retrieves <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x21.png" xlink:type="simple"/></inline-formula> and returns <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x21.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x22.png" xlink:type="simple"/></inline-formula> to verifier who, in turn, decrypt <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x21.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x22.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x23.png" xlink:type="simple"/></inline-formula> where<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x21.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x22.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x23.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x24.png" xlink:type="simple"/></inline-formula>, then compute <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x21.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x22.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x23.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x24.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x25.png" xlink:type="simple"/></inline-formula> and<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x21.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x22.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x23.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x24.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x25.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x26.png" xlink:type="simple"/></inline-formula>. The verifier checks whether<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x21.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x22.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x23.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x24.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x25.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x26.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x27.png" xlink:type="simple"/></inline-formula>. If the check succeeds, the function outputs “success”, otherwise the function outputs “failure”.</p><p>The following is the protocol flow Chart 1.</p></sec><sec id="s3"><title>3. Security Analysis</title><p>Security means that the protocol is secure against the un-trusted server and is private against third-party verifiers. Client should not be able to pass verification unless it has access to complete unaltered version of m. Firstly, we think the remote server is not trusted; he can intentionally or unintentionally change the client’s data.</p><p>Lemma 1. This probability is negligible for a secure hash function, the attacker X is able to successfully find m' which with known file m has a function of the same value and is different from m:</p><disp-formula id="scirp.76621-formula267"><graphic  xlink:href="http://html.scirp.org/file/76621x28.png"  xlink:type="simple"/></disp-formula><p>Chart 1. Protocol flow chart.</p><disp-formula id="scirp.76621-formula268"><graphic  xlink:href="http://html.scirp.org/file/76621x29.png"  xlink:type="simple"/></disp-formula><p>Theorem 1. The proposed protocol uses secure hash functions<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x30.png" xlink:type="simple"/></inline-formula>, <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x30.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x31.png" xlink:type="simple"/></inline-formula>and secure private key encryption scheme, according to the lemma 1, it is known that the attacker X can tamper with the data and the probability of success is negligible.</p><p>Proof. Assume that the un-trusted server has taken the <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x32.png" xlink:type="simple"/></inline-formula> tampering with <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x32.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x33.png" xlink:type="simple"/></inline-formula> in the query results, then he computes<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x32.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x33.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x34.png" xlink:type="simple"/></inline-formula>, <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x32.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x33.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x34.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x35.png" xlink:type="simple"/></inline-formula>, according to the above lemma<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x32.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x33.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x34.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x35.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x36.png" xlink:type="simple"/></inline-formula>. So it is the same as <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x32.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x33.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x34.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x35.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x36.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x37.png" xlink:type="simple"/></inline-formula> by the nature of the hash function. Therefore, the attacker can tamper with the data and the probability of success is negligible.</p><p>It is important to note that in the verification phase of the verifier decrypts<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x38.png" xlink:type="simple"/></inline-formula>, the probability of obtaining the message <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x38.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x39.png" xlink:type="simple"/></inline-formula> is negligible, thus this protocol support third-party security verification</p><p>Then for the security of the agreement phase, the message is sent through the private key signature and the probability of the adversary’s forgery signature is very small. Furthermore the message does not involve secret information. Agreement stage is only to ensure that the certification is received by the main body of the test will, so as to carry out data integrity testing.</p></sec><sec id="s4"><title>4. Data Dynamics</title><p>Now we show how our scheme explicitly and efficiently handle fully dynamic data operations including data modification (M), data insertion (I), data deletion (D) and data append (A) for cloud data storage. Note that in the following descriptions for the protocol design of dynamic operation, we assume that the file <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x40.png" xlink:type="simple"/></inline-formula> and the signature <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x40.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x41.png" xlink:type="simple"/></inline-formula> have already been generated and properly stored at server. The update operation is illustrated in Algorithm 1.</p><disp-formula id="scirp.76621-formula269"><graphic  xlink:href="http://html.scirp.org/file/76621x42.png"  xlink:type="simple"/></disp-formula><sec id="s4_1"><title>4.1. Data Modification</title><p>We start from data modification, which is one of the most frequently used operations in cloud data storage. A basic data modification operation refers to the replacement of specified blocks with new ones.</p><p>Suppose the client wants to modify the i-th block <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x43.png" xlink:type="simple"/></inline-formula> to<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x43.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x44.png" xlink:type="simple"/></inline-formula>, first the client generates the corresponding signature<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x43.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x44.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x45.png" xlink:type="simple"/></inline-formula>.Step completely in accordance with the above update algorithm, the update request message here is “<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x43.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x44.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x45.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x46.png" xlink:type="simple"/></inline-formula>” and sends it to the server, where M denotes the modification operation.</p><p>Upon receiving the request, the server runs</p><p><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x47.png" xlink:type="simple"/></inline-formula>. Specifically, the server replaces the block <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x47.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x48.png" xlink:type="simple"/></inline-formula> with <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x47.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x48.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x49.png" xlink:type="simple"/></inline-formula> and <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x47.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x48.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x49.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x50.png" xlink:type="simple"/></inline-formula> with<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x47.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x48.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x49.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x50.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x51.png" xlink:type="simple"/></inline-formula>, then computes<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x47.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x48.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x49.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x50.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x51.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x52.png" xlink:type="simple"/></inline-formula>. Finally, the server responses the client with a proof for this operation<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x47.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x48.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x49.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x50.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x51.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x52.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x53.png" xlink:type="simple"/></inline-formula>. After receiving the proof for modification operation from server, the client first decrypts<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x47.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x48.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x49.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x50.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x51.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x52.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x53.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x54.png" xlink:type="simple"/></inline-formula>, then checks whether</p><p><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x55.png" xlink:type="simple"/></inline-formula>. If it is not true, output FALSE, otherwise output TRUE.</p></sec><sec id="s4_2"><title>4.2. Data Insertion</title><p>Data is inserted into the existing block in the operation are exactly the same with data modification. For the insertion of a single data block, this paper considers that the data files in a data block can be assigned to one or more existing data blocks and also can perform data modification operations.</p></sec><sec id="s4_3"><title>4.3. Data Deletion</title><p>Data deletion is just the opposite operation of data insertion. Suppose the server receives the update request for deleting block m<sub>i</sub>, it will replace the block m<sub>i</sub> with DBlock, which DBlock is a fixed special block that represents deleted blocks. The details of the protocol procedures are similar to that of data modification and insertion, which are thus omitted here.</p></sec><sec id="s4_4"><title>4.4. Data Append</title><p>Compared to data modification, data append does not change steps. The difference of additional data and data update is that you need to add new data blocks we call it <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x56.png" xlink:type="simple"/></inline-formula> where<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x56.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x57.png" xlink:type="simple"/></inline-formula>, so the corresponding update request message is “<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x56.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x57.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x58.png" xlink:type="simple"/></inline-formula>”, where A denotes the modification operation. Then the verification process behind the validation process and the data modification operation is exactly the same, so here it is no longer duplicated.</p></sec></sec><sec id="s5"><title>5. Analysis of the Proposed Protocol</title><p>Our scheme is based entirely on un-symmetric key cryptography. In this section we list the features of our proposed scheme and make a comparison of our scheme and state-of-the-art. It is worth noting that we denote pseudo random number generation and addition in the corresponding fields as prng and add.</p><sec id="s5_1"><title>5.1. Computational Cost</title><p>Server side. During verification, the server computes c hash integers<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x59.png" xlink:type="simple"/></inline-formula>. Then, it computes the value<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x59.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x60.png" xlink:type="simple"/></inline-formula>. The computation of each <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x59.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x60.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x61.png" xlink:type="simple"/></inline-formula> corresponds to the product of two integers being t and h bits long. So we obtain the upper bound on the server’s computation time:</p><disp-formula id="scirp.76621-formula270"><graphic  xlink:href="http://html.scirp.org/file/76621x62.png"  xlink:type="simple"/></disp-formula><p>Verifier side. Except for additional pseudorandom num-ber generations corresponding to the challenge, the cost analysis of computing <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x63.png" xlink:type="simple"/></inline-formula> is similar to that on the client side. Therefore, the verifier computation time is upper bounded by</p><disp-formula id="scirp.76621-formula271"><graphic  xlink:href="http://html.scirp.org/file/76621x64.png"  xlink:type="simple"/></disp-formula><p>The computation cost for server and verifier, though slightly higher, is still very reasonable. This does not include the time for the verifier of the data blocks to be detected, since the computation of the c requires only a very small mathematical calculation.</p></sec><sec id="s5_2"><title>5.2. Storage Cost</title><p>Notice that each token is the output of a cryptographic hash function, so its size is small.</p><p>Server side. In line with the purpose of the protocol, the server has to store the complete data m and<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x65.png" xlink:type="simple"/></inline-formula>, whose bitlength is <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x65.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x66.png" xlink:type="simple"/></inline-formula> bits</p><p>Verifier side. The storage requirements for the verifier are only a pk, which was used in the verification phase.</p></sec><sec id="s5_3"><title>5.3. Communication Cost</title><p>The communication cost consists of the challenge sent by the verifier to the server, with constant bitlength <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x67.png" xlink:type="simple"/></inline-formula> bits, and the response sent by the server to the verifier, with constant bitlength <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x67.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/76621x68.png" xlink:type="simple"/></inline-formula> bits. It is critical to notice that the communication consumption which is ignored here in the agreement phase is very small.</p></sec><sec id="s5_4"><title>5.4. Comparison with Selected Previous Protocols</title><p>We now compare our scheme with some existing schemes in terms of communication cost, computation cost on ser- ver side, computation cost on verifier side and storage cost on verifier side. For simplicity, here we denote them as Comm.cost, Comp.cost(S), Comp.cost(V), Storage.cost(V), respectively. Data dynamics and public verifiability are also listed in the table. <xref ref-type="table" rid="table1">Table 1</xref> indicates that the proposed protocol is really minimal overhead. You should note that n denotes all the blocks.</p></sec></sec><sec id="s6"><title>6. Conclusion</title><p>In this paper, we propose a new remote data integrity checking protocol for cloud storage. We extend the PDP model [<xref ref-type="bibr" rid="scirp.76621-ref3">3</xref>] by changing the generation method of the signature. The proposed protocol supports data level dynamics and public verifiability. Meanwhile, it is desirable to minimize the file block accesses, the</p><table-wrap id="table1" ><label><xref ref-type="table" rid="table1">Table 1</xref></label><caption><title> Comparisons between the proposed protocol and previous protocols</title></caption><table><tbody><thead><tr><th align="center" valign="middle" >SchemeMetric</th><th align="center" valign="middle" >[<xref ref-type="bibr" rid="scirp.76621-ref6">6</xref>]</th><th align="center" valign="middle" >[<xref ref-type="bibr" rid="scirp.76621-ref4">4</xref>]</th><th align="center" valign="middle" >[<xref ref-type="bibr" rid="scirp.76621-ref7">7</xref>]</th><th align="center" valign="middle" >[<xref ref-type="bibr" rid="scirp.76621-ref3">3</xref>]</th><th align="center" valign="middle" >[<xref ref-type="bibr" rid="scirp.76621-ref10">10</xref>]</th><th align="center" valign="middle" >Our scheme</th></tr></thead><tr><td align="center" valign="middle" >Data dynamics</td><td align="center" valign="middle" >Yes</td><td align="center" valign="middle" >Yes</td><td align="center" valign="middle" >Yes</td><td align="center" valign="middle" >Yes</td><td align="center" valign="middle" >Yes</td><td align="center" valign="middle" >Yes</td></tr><tr><td align="center" valign="middle" >Public verifiability</td><td align="center" valign="middle" >No</td><td align="center" valign="middle" >Yes</td><td align="center" valign="middle" >Yes</td><td align="center" valign="middle" >No</td><td align="center" valign="middle" >Yes</td><td align="center" valign="middle" >Yes</td></tr><tr><td align="center" valign="middle" >Comp.cost(S)</td><td align="center" valign="middle" >O(logn)</td><td align="center" valign="middle" >O(logn)</td><td align="center" valign="middle" >O(n)</td><td align="center" valign="middle" >O(1)</td><td align="center" valign="middle" >O(logn)</td><td align="center" valign="middle" >O(1)</td></tr><tr><td align="center" valign="middle" >Comp.cost(V)</td><td align="center" valign="middle" >O(logn)</td><td align="center" valign="middle" >O(logn)</td><td align="center" valign="middle" >O(n)</td><td align="center" valign="middle" >O(1)</td><td align="center" valign="middle" >O(logn)</td><td align="center" valign="middle" >O(1)</td></tr><tr><td align="center" valign="middle" >Comm.cost</td><td align="center" valign="middle" >O(logn)</td><td align="center" valign="middle" >O(logn)</td><td align="center" valign="middle" >O(1)</td><td align="center" valign="middle" >O(1)</td><td align="center" valign="middle" >O(logn)</td><td align="center" valign="middle" >O(1)</td></tr><tr><td align="center" valign="middle" >Storage cost(V)</td><td align="center" valign="middle" >O(1)</td><td align="center" valign="middle" >O(1)</td><td align="center" valign="middle" >O(n)</td><td align="center" valign="middle" >O(1)</td><td align="center" valign="middle" >O(1)</td><td align="center" valign="middle" >O(1)</td></tr></tbody></table></table-wrap><p>computation on the server and the client-server communication. We expect that the salient features of our scheme make it attractive for realistic applications.</p></sec><sec id="s7"><title>Acknowledgements</title><p>This work was supported by the Natural Science Foundation of China (61163001).</p></sec><sec id="s8"><title>Cite this paper</title><p>Feng, J.J. and Long, S.G. (2017) Data Integrity Checking Protocol with Data Dynamics in Cloud Computing. Int. J. Communications, Network and System Sciences, 10, 274-282. https://doi.org/10.4236/ijcns.2017.105B027</p></sec></body><back><ref-list><title>References</title><ref id="scirp.76621-ref1"><label>1</label><mixed-citation publication-type="other" xlink:type="simple">Tan, S., Jia, Y. and Han, W.H. (2015) Research and Development of Provable Data Integrity in Cloud Storage. Chinese Journal of Computers, 38, 164-177.</mixed-citation></ref><ref id="scirp.76621-ref2"><label>2</label><mixed-citation publication-type="other" xlink:type="simple">Ateniese, G., Bruns, R. and Curtmola, R. (2007) Provable Data Possession at Untrusted Stores. Pro-ceedings of the 14th ACM Conference on Computer and Communications Security, Alexandra, 598-609. https://doi.org/10.1145/1315245.1315318</mixed-citation></ref><ref id="scirp.76621-ref3"><label>3</label><mixed-citation publication-type="other" xlink:type="simple">Ateniese, G., Pietro, R.D., Mancini, L. and Tsudik, G. (2008) Scalable and Efficient Provable Data Possession. Proceedings of the 4th International Conference on Security and Privacy in Communication Networks, Istanbul, 1-10.  
https://doi.org/10.1145/1460877.1460889</mixed-citation></ref><ref id="scirp.76621-ref4"><label>4</label><mixed-citation publication-type="other" xlink:type="simple">Wang, Q., Wang, C., Li, J. and Lou, W.J. (2009) Enabling Public Verifiability and Data Dynamics for Storage Security in Cloud Computing. Proceedings of the 4th European Symposium on Research in Computer Security, Saint Malo, 355-370. 
https://doi.org/10.1007/978-3-642-04444-1_22</mixed-citation></ref><ref id="scirp.76621-ref5"><label>5</label><mixed-citation publication-type="other" xlink:type="simple">Mao, J., Zhang, Y., Li, P., Wu, Q.H. and Liu, J.W. (2015) A Position-Aware Merkle Tree for Dynamic Cloud Data Integrity Verification. Soft Computing.  
https://doi.org/10.1007/s00500-015-1918-8</mixed-citation></ref><ref id="scirp.76621-ref6"><label>6</label><mixed-citation publication-type="other" xlink:type="simple">Erway, C., Kupcu, A., Papamathou, C. and Tamassia, R. (2009) Dynamic Provable Data Possession. Proceedings of the 16th ACM Conference on Computer and Communications Security, Chicago, 213-222. 
http://doi.org/10.1145/1653662.1653688</mixed-citation></ref><ref id="scirp.76621-ref7"><label>7</label><mixed-citation publication-type="other" xlink:type="simple">Hao, Z., Zhong, S. and Yu, N.H. (2011) A Privacy-Preserving Remote Data Integrity Checking Protocol with Data Dynamics and Public Verifiability. IEEE Transactions on Knowledge and Data Engineering, 23, 1432-1437. 
https://doi.org/10.1145/1653662.1653688</mixed-citation></ref><ref id="scirp.76621-ref8"><label>8</label><mixed-citation publication-type="other" xlink:type="simple">Xu, W., Feng, D. and Liu, J.N. (2012) Remote Data Integrity Checking Protocols from Homomorphic Hash Functions. Proceedings of 2012 IEEE 14th International Conference on Communication Technology, Chengdu, 604-608 
https://doi.org/10.1109/TKDE.2011.62</mixed-citation></ref><ref id="scirp.76621-ref9"><label>9</label><mixed-citation publication-type="other" xlink:type="simple">Zhu, Y., Ahn, G.-J., Hu, H.X., Yau, S.S., An, H.G. and Hu, C.-J. (2013) Dynamic Audit Services for Outsourced Storages in Clouds. IEEE TSC, 6, 227-238.  
https://doi.org/10.1109/ICCT.2012.6511277</mixed-citation></ref><ref id="scirp.76621-ref10"><label>10</label><mixed-citation publication-type="other" xlink:type="simple">Tang, C.-M. and Zhang, X.J. (2015) A New Publicly Verifiable Data Possession on Remote Storage. Journal of Supercomputing, 1-15. 
https://doi.org/10.1007/s11227-015-1556-z</mixed-citation></ref><ref id="scirp.76621-ref11"><label>11</label><mixed-citation publication-type="other" xlink:type="simple">Hu, D.M. and Yu, X. (2014) Dynamic Cloud Storage Data Integrity Verifying Me-thod Based on Homomorphic Tags. Application Research of Computers, 31, 1362-1395. https://doi.org/10.1007/s11227-015-1556-z</mixed-citation></ref><ref id="scirp.76621-ref12"><label>12</label><mixed-citation publication-type="other" xlink:type="simple">Hu, D.M. and Yu, X. (2014) Dynamic Data Integrity Detection Method in Cloud Storage Service. Application Research of Computers, 31, 3056-3060.</mixed-citation></ref><ref id="scirp.76621-ref13"><label>13</label><mixed-citation publication-type="other" xlink:type="simple">Ateniese, G., Burns, R., Curtmola, R., Herring, J., Khan, O., Kissner, L., Peterson, Z. and Song, D. (2011) Remote Data Checking Using Provable Data Possession. ACM Transactions on Information and System Security, 14, 1-34. 
https://doi.org/10.1145/1952982.1952994</mixed-citation></ref><ref id="scirp.76621-ref14"><label>14</label><mixed-citation publication-type="other" xlink:type="simple">Li, A.P., Tan, S. and Jia, Y. (2016) A Method for Achieving Provable Data Integrity in Cloud Computing. Journal of Supercomputing, 1-17.  
https://doi.org/10.1145/1952982.1952994</mixed-citation></ref><ref id="scirp.76621-ref15"><label>15</label><mixed-citation publication-type="other" xlink:type="simple">Juels, A. and Kaliski, B.S. (2007) PORs: Proofs of Retrievability for Large Files. Proceedings of the 14th ACM Conference on Computer and Communications Security, Whistler, 584-597. https://doi.org/10.1145/1315245.1315317</mixed-citation></ref></ref-list></back></article>