System Model

A representative network architecture for cloud data storage is illustrated in Figure 1. Different network
entities that can be defined in cloud system is as follows:
• User:
Users, who have data to be stored in the cloud and trust on the cloud for data computation, it consists of
both individual consumers and organizations.
• Cloud Service Provider (CSP):
A CSP, who has significant resources and expertise in building and managing distributed cloud storage
servers, preserves and functions live Cloud Computing systems.
• Third Party Auditor (TPA):
An optional TPA, has the skills and capabilities that normal users do not have, it uses to trust the assess
and expose risk of cloud storage services on behalf of the users upon the request generates. In cloud data
storage, a user stores his data through a CSP into a set of cloud servers, which are running in a concurrent,
collaborated and in distributed manner. Data redundancy can be active with technique of erasure-correcting
code to further endure faults or server crash as user’s data grows in dimensions and importance of it
increases.
Thereafter, for application purposes, the user cooperates with the cloud servers through CSP to access or
recover his data. In some cases, the user may need to do block level operations on his data.
Cloud data storage architecture include the type of operations like block update, delete, insert and append.
As users no longer possess their data in their domain, so it is importance to guarantee users that their data
are being properly stored and preserved. That is, users should be armed with security means so that they
can make continuous correctness declaration of their stored data even without the being of local copies. In
case that users do not necessarily have the time, feasibility or resources to monitor their data, they can
delegate the tasks to an optional trusted TPA of their respective choices. In the model, we adopt that the
point-to-point communication channels between each cloud server and the user is authentic and consistent,
which can be accomplished in practice with little upstairs.
A. Adversary Model
Security threats or security faults in cloud data storage can arrive from two different foundations. On the
one hand, a CSP can be self-centered, untrusted and possibly malicious. Not only does it wish to move data
that has not been or is seldom accessed to a lower tier of storage than agreed for monetary reasons, but it
may also attempt to hide a data loss incident due to management errors, Byzantine failures and many
others. On the other way, there may also exist a frugally motivated adversary, who has the ability to
compromise a numerous of cloud data storage servers in different time interval and later is able to modify
or remove user data while remaining unrecognized by CSPs for a certain period of time.
There are two types of advisory model:
Weak Adversary:
The adversary is involved in demeaning the user’s data files stored on individual servers or cloud. Once a
server is contained, an adversary can change or modify the original data files by adding or modifing its own
fault data to prevent the original data from being recovered by the user.
Strong Adversary:
This is the scenario which can be called as worst-case scenario, in which we undertake that the adversary
can negotiation all the storage servers so that he can purposely modify the data files as long as they are
within consistent. In fact, this is equivalent to the case where all servers are conspiring together to hide a
data loss or corruption event.

B. Design Goals
To safeguard the security and dependability for cloud data storage under the above-mentioned adversary
model, we aim to design and develop an efficient mechanism for dynamic data verification and operation
and achieve the following goals:
(1) Storage correctness: to ensure users that their data are certainly stored appropriately and kept complete
all the time in the cloud.
 (2) Fast localization of data error: to effectively locate the faulty server when data corruption has been
found.
(3) Dynamic data support: to maintain the same level of storage accuracy assurance even if users modify,
delete or append their data files in the cloud.
(4) Dependability: to enhance data availability against Byzantine failures, malicious data modification and
server conspiring attacks, i.e. minimizing the effect brought by data errors or server failures.
(5) Lightweight: to enable users to perform storage correctness checks with lowest overhead.