Abstract
With popularization of cloud services, multiple users easily share and update their data through cloud storage. For data integrity and consistency in the cloud storage, the audit mechanisms were proposed. However, existing approaches have some security vulnerabilities and require a lot of computational overheads. This paper proposes a secure and efficient audit mechanism for dynamic shared data in cloud storage. The proposed scheme prevents a malicious cloud service provider from deceiving an auditor. Moreover, it devises a new index table management method and reduces the auditing cost by employing less complex operations. We prove the resistance against some attacks and show less computation cost and shorter time for auditing when compared with conventional approaches. The results present that the proposed scheme is secure and efficient for cloud storage services managing dynamic shared data.
1. Introduction
Cloud computing is a promising paradigm to create various computing environments such as [1–3]. Cloud service provider (CSP) allows network-connected users to make use of computing resources in a remote location. As the usage of cloud service matures, users try to share their data in cloud storage and process the data efficiently at a low cost [3–5]. Although several CSPs such as Google [6] and Amazon [7] support computing environments for shared data, integrity of outsourced data is hard to be guaranteed. Due to the lack of transparency, users delegate the control for data management to the third-party CSP but there is no way for users to be noticed about data loss or modification occurred at the cloud storage. In addition, for the reputation of the cloud service, CSPs are reluctant to reveal data inconsistency caused by external threats, software/hardware failures, inside attacks, and so on. Therefore, audit mechanisms are required for verifying consistent data management in the cloud storage.
There are several studies verifying integrity of outsourced data at untrusted storages [8–18]. Most of them [8–14] are yet to consider a situation where the same data is shared by multiple users. In these approaches, only a single user is allowed to update his own data. And he can audit the data either by himself [8, 9, 13] or with assistance from a third-party auditor (TPA) [10–12, 14]. Recent studies [16–18] consider audit for shared data but they only support a limited number of data updates. In addition, the CSP can cheat on censorship in these schemes since an index table used for verification is managed only by the CSP. One way to prevent such a cheat is to make users and the TPA also maintain the index table. Owing to storage and synchronization overhead, however, it might cause a significant delay and degrade the quality of service (QoS) as the number of data updates increases.
In order to design a secure and efficient audit mechanism for dynamic shared data in cloud storage, aforementioned challenges should be efficiently addressed. In other words, the scheme must guarantee the following properties.(1)Audit for Outsourced Data. The TPA is able to check the integrity of outsourced data without retrieving all data contents.(2)Shared Dynamic Data. Users are allowed to outsource, share, insert, delete, or modify their data contents without restriction.(3)Efficiency. Computational overhead for data outsourcing and update at users side as well as the ones for auditing at the TPA should be low.(4)Soundness. The CSP is not allowed to deceive users or the TPA into passing a censorship of damaged data contents.
We propose an audit mechanism satisfying the above requirements by utilizing aggregate signature [19] and sample auditing [8]. For data integrity and consistency, the TPA manages an index table and the CSP keeps renewing an identifier for data update. In addition, the audit mechanism provides efficiency to users and the TPA through making the auditing operations simple. Specially, in this paper, we consider forge attack and replace attack as regards soundness for the sake of secure audit. These attacks are described in [20] and they can be summarized as follows. Forge attack is an attack to forge a verifying term for a data content, which was not actually outsourced by users. Replace attack is an attack to pass a censorship by choosing another data content for verification in place of the damaged data content.
The rest of this paper is organized as follows. In Section 2, we introduce related works about auditing data in the cloud storage. In Section 3, issues about index table management are described depending on which entity manages it. In Section 4, we present methods for our audit mechanism. In Section 5, preliminaries used in our work are briefly introduced. In Section 6, a secure and efficient audit mechanism for dynamic shared data is presented. In Section 7, security of the proposed scheme is analyzed. In Section 8, performance evaluations and experimental results show efficiency of our mechanism. Finally, we conclude our work in Section 9.
2. Related Work
Ateniese et al. firstly introduced the notion of provable data possession (PDP) in [8] for integrity check of outsourced data in untrusted storage. They could achieve efficient audit with high probability of detection by sampling random blocks from outsourced data instead of downloading the entire data. Since the original PDP does not consider dynamic data, a user should download the whole data and regenerate metadata for verification whenever there is a modification of the outsourced data. To provide audit for dynamic data without retrieving entire data, subsequent works adopted authenticated data structures such as skip list, Merkle tree, or index tables [9, 12, 14–18]. Erway et al. [9] proposed dynamic provable data possession (DPDP) based on rank-based authenticated skip list and Wang et al. [12] presented a mechanism by exploiting Merkle tree. Both schemes require reconstruction of the authenticated data structure when the corresponding data is updated. Another data structure called index table was introduced to handle data updates more efficiently by keeping unique identifier for each data block [14–18].
It is also notable that outsourced data should be audited periodically for verifying consistent data management. Dedicated to this purpose, TPAs can be delegated by users for auditing outsourced data in privacy-preserving manner. Privacy preservation means that the TPA cannot learn any information about the data during audit process. It was achieved through the methods of random masking [11] and bilinear map [14].
3. Index Table Management
Previous works [14–18] utilized an index table for efficient data updates. It is composed of indices which represent the sequences of data blocks and identifiers. The identifier, which is used in tag (tag is a verifying term, stored with data in the cloud storage, and has consistency with a data block) generation and verification, is a number identifying each data block. It should be defined in order to keep the initial value in all circumstances. Otherwise, a user repeats following operations whenever identifiers of data blocks in the cloud storage are changed. The user downloads data blocks which have changed identifiers, regenerates tags of them, and uploads the tags to the cloud storage.
In this section, we look into security issues and update flows depending on which entity manages an index table. At the security aspect, we check the possibility of forge attack and replace attack. Then, we describe communication flows for getting an identifier of new data block when a user tries to update.
3.1. Management by the CSP
When the CSP only manages an index table, users and the TPA do not have any information about identifiers of data blocks which are already uploaded and will be updated. As illustrated in Figure 1, the user requests an identifier of new data block to the CSP when he tries to update. In this environment, the CSP can forge tags of data blocks which users have not uploaded. It transmits an identifier already existed in the index table then obtains tags which are of different data blocks but have same identifier. It can learn meaningful information for forgery through combination of these data blocks and tags.
Since the TPA needs identifiers of challenged data blocks when verifying, it receives a proof that includes the identifiers from the CSP [16–18]. However, the TPA cannot distinguish them from the challenged ones because it does not maintain an index table. Therefore, if challenged data blocks are modified or deleted, the CSP can replace them with other undamaged data blocks.
3.2. Management by the TPA
One simple way to prevent the forge attack and replace attack in the above case is that the TPA manages an index table [15]. Even though the CSP tries to launch a forge attack by exploiting a collision of identifiers, it is impossible because the CSP has no knowledge of identifiers. In addition, a replace attack can be detected easily because the TPA knows identifiers of challenged data blocks through the index table.
Figure 2 shows that the TPA participates in the update process and a user who tries to update cannot generate a tag for new data block without a reception of new identifier from the TPA. Accordingly, update process can be delayed when the TPA is on sleep or suffers from bottleneck caused by a large number of requests from users.
3.3. Management by Both the TPA and Users
Delays of update process can be removed through managing an index table by a user directly [14]. Generally, it is suitable for a situation where data is not shared. However, it has a problem about synchronization of index tables because the index tables are managed separately by each individual user who shares the data. If they are not synchronized, identifiers generated by other users can have same value, then the CSP can exploit forge attack or replace attack by using such tags generated by the same identifiers.
Broadcasting update information, after a user finished data update, is a solution for synchronization as shown in Figure 3. However, it requires all users to always wake up. Otherwise, the users need to request the information for synchronization but cannot easily determine who has the newest index table. Although the users can request it to the TPA, this is not different from a previous way that the only TPA manages an index table.
4. Methods
In this section, we present methods for a secure and efficient audit mechanism for shared dynamic data.
4.1. System Model
Our system model for auditing mechanism is illustrated in Figure 4. There are four entities: CSP, initial uploader, users, and TPA. The CSP provides a large-scale storage for shared data to users. It should process requests from authorized users and respond to every challenge from the TPA. An initial uploader uploads data to cloud storage firstly and forms a group of users who share the data together. Users in the group are able to access and update shared data in the cloud storage. Both an initial uploader and the users are able to audit shared data in cloud storage via the TPA delegated by the initial uploader.
4.2. Secure and Efficient Index Table Management
We propose a secure and efficient index table management that is used for our audit mechanism. As mentioned in the previous section, a TPA must manage an index table to prevent forge attack and replace attack. However, delay and synchronization problems can be caused when the index table is managed by the only TPA or each user. To solve these problems, it is required that a user who tries to update obtains an identifier from the CSP, as described in Figure 5. Consequently, a way that the TPA manages an index table and the CSP keeps renewing an identifier for new data block satisfies security and efficiency.
4.3. Identifier Definition for Dynamic Data
Changing identifiers of data blocks by update process causes repetitive tasks to users. They download the corresponding data blocks, regenerate tags to apply the modified identifiers, and upload the tags again to cloud storage. Our mechanism removes these repetitive tasks by defining the identifier as an upload sequence of the data block. If an update of data block happens, then new identifier is assigned as the upload sequence from the CSP.
4.4. Simple Operations for Audit Mechanism
Conventional approaches employ relatively complex operations for audit mechanism. It may cause more delay time and computational overhead for tag generation and verification. For efficiency of audit mechanism, the proposed scheme utilizes simple operations in the data integrity check. Moreover, because it can reduce delay time and computational overhead through light-weight operations, the QoS of the cloud storage service is improved.
5. Preliminaries
In this section, cryptographic backgrounds for the proposed scheme are briefly introduced.
5.1. Bilinear Map
Let and be multiplicative cyclic groups of prime order , and let be a generator of . Then a bilinear map satisfies the following properties.(1)Bilinearity: for any , and .(2)Nondegeneracy: .(3)Computability: there exists an efficiently computable algorithm satisfying the above properties such that .
5.2. Pseudorandom Permutation
Let be an efficiently computable keyed permutation for positive integer . We say that is a pseudorandom permutation, if there exists a negligible function for any probabilistic polynomial-time distinguisher such that where is a permutation key chosen uniformly at random and is a real-random permutation.
5.3. Discrete Logarithm (DL) Assumption
Discrete logarithm (DL) problem is to compute , given and . The DL assumption holds in if it is computationally infeasible to solve DL problem in .
6. The Proposed Scheme
In this section, we present a secure and efficient audit mechanism supporting dynamic updates of shared data. When cloud storage service initiates, a CSP generates public parameters for system and publicizes them. An initial uploader generates secret components and public components used in tag generation and verification. He divides data into blocks and generates tags for each data block. Then, he uploads them to the cloud storage and deletes them in his local storage. To share the data with other users, he needs to deliver secret components for tag generation. In addition, he can delegate auditing processes to a TPA by delivering a part of secret components for verification.
When a user tries to update a new data block, he receives an identifier from the CSP, generates a tag for the data block, and uploads them. After update is finished, the user reports update information to the TPA. Then the TPA updates an index table following the update information. And the CSP renews the identifier as next upload sequence for next update.
The TPA maintains the newest index table that keeps track of upload sequence of data blocks. The TPA makes a challenge derived from the index table and transmits it to the CSP periodically or when a user wants. The CSP who receives the challenge makes a proof and responds to it. Then, the TPA checks whether outsourced data is damaged or not by verifying the proof with the challenge.
6.1. Definition
The proposed scheme, , is composed of the following eight algorithms such as .
. On security parameter , the CSP generates and publicizes public parameters .
. An initial uploader takes public parameter as input and outputs group master key , group secret key , group auditing key , and group public key . Group master key is kept secret. Group secret key and group auditing key are used in tag generation. Group public key is used for verification of data integrity along with group auditing key .
. On uploading data to the cloud storage, the initial uploader divides the data into blocks and generates a set of tags using and . Each component of is a tag of the corresponding data block in such that .
. When a user tries to update a data block , he generates a new tag using , , and new identifier received from the CSP.
. This algorithm takes update information and current index table as input and outputs new index table . The update information includes three elements , and . represents an update type which can be either insertion, modification, or deletion. is the index of the data block to be updated, and is a newly assigned unique identifier used in for the data block.
. This algorithm generates a challenging query for randomly selected blocks. The TPA chooses random indices from the index table and generates random values .
. The CSP generates a proof for a challenge from the TPA. is derived from outsourced data blocks , , and , while is computed from tags and .
. This algorithm verifies consistency of the proof generated by the CSP for the given challenge. If they are consistent, it outputs . Otherwise, it outputs .
6.2. Construction
Let be multiplicative cyclic groups of prime order , let be a generator of , let be a bilinear map, and let be a pseudorandom permutation. We consider data is divided into blocks as , and each data block contains sectors of .
6.2.1. Setup
When cloud storage service initiates, the CSP chooses two groups with for a bilinear map by running algorithm and publicizes to users and the TPA.
6.2.2. Upload for Data Sharing
An initial uploader, , runs algorithm. It first chooses random values , , and and computes , and . Then, by running , generates corresponding tags such as for . uploads to the cloud storage and deletes them from his local storage. When the CSP receives fresh data from the initial uploader, it saves an identifier for the next upload sequence. To share data with other users, delivers group secret key and group auditing key to them.
6.2.3. Delegation of Audit
The initial uploader delegates audit for shared data to the TPA by delivering a group auditing key . In addition, notifies the number of data blocks for the TPA to correctly generate an initial index table for . In other words, the TPA creates an index table which includes identifiers defined as block sequences initially.
6.2.4. Data Update
In the proposed scheme, any user in the group which shares data is allowed to modify, insert, or delete data in the cloud storage.
If tries to modify -th block , first receives a new identifier from the CSP as illustrated in Figure 5. On receipt of the identifier , computes a tag for updated data block by running algorithm as follows: Then, sends along with to the CSP, where stands for modification. The CSP can update the data block in the cloud storage by replacement of with uploaded by .
For the case of insertion, makes a tag for newly created data block by running algorithm and sends along with to the CSP.
When wants to delete data block in the cloud storage, sends to the CSP and allows the CSP to delete the corresponding data block from the cloud storage. In this case, does not need to request a new identifier. Therefore, we set the value of by zero.
After update is finished, delivers update information to the TPA for consistent audit for updated shared data in the cloud storage. Then, the TPA updates the index table managed by itself according to the information by running . When , it changes the -th identifier to . When , the TPA inserts just before the -th field, while it removes the -th field from the index table if . Through this notification of data updates, the TPA can detect malicious behaviors of the CSP. In other words, the CSP cannot transmit previously used identifier in order to exploit forge attack and replace attack. Simple examples of data update are depicted in Figure 6.
6.2.5. Audit for Outsourced Data
For the TPA to check integrity of outsourced data, it engages in challenge-response protocol with the CSP. The TPA first chooses a random subset of indices from the index table and generates random values by running algorithm. The is transmitted to the CSP and the CSP generates a proof for the challenge by running algorithm as follows:
After receiving the proof as a response of the challenge, the TPA verifies it by running algorithm as follows:
If (5) holds then the TPA returns and returns otherwise.
7. Security Analysis
In this section, we show that the proposed scheme is correct and resistant against forge attack and replace attack.
Theorem 1. provides correctness to the TPA during auditing outsourced data.
Proof. Correctness of is achieved by exploiting bilinear property of the bilinear map. Left-hand side (LHS) of (5) expands as follows:
while the right-hand side (RHS) of (5) expands as follows:
Since the terms LHS and RHS are the same, the proof is completed.
Theorem 2. is secure against forge attack.
Proof. If the CSP acquires an element in from the public parameter , the CSP can forge a tag. Given , computing is hard due to DL assumption. Thus, it is infeasible for the CSP to acquire an element in .
When for and for are the same, the CSP computes . Then, the CSP can obtain and forge the tag of data block using as follows:
Finally, the CSP obtains forged tag of modified data block . However, and cannot be the same value for because of the definition of pseudorandom permutation. Therefore, the CSP cannot forge a tag to pass the censorship. This completes the proof.
Theorem 3. is secure against replace attack.
Proof. When damaged block is challenged, the CSP may try to pass the censorship by choosing a different block in place of such as and . Then, the left-hand side of (5) is computed as in which should be 1 to satisfy (5). This means that and should be the same. Due to the bijective property of the permutation, however, these values cannot be the same.
8. Performance Evaluation
In this section, the prosed scheme is analyzed and compared with previous studies [14–16] in terms of communication and computational overhead. We first evaluate communication overhead for updating a data block. Then, computational overhead for tag generation and verification is evaluated.
8.1. Communication Overhead
As we described in Section 3, the way to get an identifier of updated data block depends on which entity manages an index table. In Wang et al.’s work [16], needs one round-trip communication to request and receive the identifier (Figure 1). Zhu et al. [15] utilize a way that the TPA manages the index table (Figure 2). It needs an additional connection between and the TPA for the identifier and a report of update information. Yang and Jia [14] utilize a way that a user manages the index table by himself. Although it is suitable when the outsourced data is managed by a single user, it requires more communication costs for synchronization of the index tables when the data is shared by multiple users.
Communication costs are summarized in Table 1. We omitted costs for uploading a data block and a corresponding tag for simplicity. Although the proposed scheme seems to require the same cost as Zhu et al.’s approach, there may be update delays caused by concentration of communications to the TPA in [15]. On the other hand, the proposed scheme removes this delay via a direct acquisition of the identifier from the CSP. For [14] to synchronize the index tables of users and the TPA, needs to broadcast extra update information. Considering this circumstance, additional communications caused by broadcast might be added into Table 1.
8.2. Computational Overhead
Computation costs for tag generation and verification are described in Table 2. The proposed scheme requires a single operation in tag generation, while the others [14–16] require and operations which are proportional to the number of sectors in a data block. When the TPA verifies a proof received from the CSP, one and one operations are required in the proposed scheme regardless of the number of challenged data blocks. However, the others require and operations linear to the number of challenged data blocks, which cause a significant overhead to the TPA.
8.3. Experimental Results
We measure the performance of our scheme and compare it with other works [14–16] based on implementations in Ubuntu 12.04. We utilize Paring Based Cryptography (PBC) library for cryptographic operations and OpenSSL to use Advanced Encryption Standard (AES) for pseudorandom permutation. All experiments are executed on an Intel Core i3 3.10 GHz with 2 GB memory. We assume that is 160 bits, is 80 bits, and size of a data block is 160 bits. We simulate each scheme on 4 different data which has 1,000 data blocks with 5 times. All experimental results show an average of 20 trials.
8.3.1. Tag Generation
The performances of the tag generation times are presented in Figure 7(a). Tag generation time in our scheme is 3.18 milliseconds per block when and 3.28 milliseconds per block when . Since a single is required regardless of , almost never influences on tag generation time. However, tag generation times of the others increase with increasing . Reference [16] requires 323.65 milliseconds per block, and [14] requires 324.63 milliseconds per block when . Since they have same computation complexity, their tag generation times are almost identical. Reference [15] needs one more . Thus, it requires 329.97 milliseconds per block which is more than the others.
| (a) Impact of on tag generation time |
| (b) Impact of on verification time, when |
| (c) Impact of on verification time, when |
8.3.2. Verification
We measure verification times depending on when . As depicted in Figure 7(b), the verification times for the TPA are dependent on in the others [14–16]. When , [14–16] requires 5.13, 5.66, and 5.75 seconds, respectively. Furthermore, Figure 7(c) shows that influences [15, 16]. However, our scheme requires 0.01 seconds for verification regardless of and .
9. Conclusion
In this paper, we present a secure and efficient audit mechanism for shared dynamic data in cloud storage. It makes possible for the TPA to correctly audit outsourced data which can be updated in a secure manner. With simple index table management by the TPA and identifier renewal by the CSP, any user in a group can update shared data block efficiently. Furthermore, making the auditing operations simple leads to less computational overhead for the whole auditing process. Performance evaluation and security analysis show that the proposed scheme is best suited to the cloud storage where multiple users share and update the outsourced data frequently.
Notations
| : | A user who tries to update |
| : | The number of users in group |
| : | The number of challenged data blocks |
| : | The number of sectors in a data block |
| : | An identifier |
| : | Request for an identifier |
| : | Update information |
| : | Pseudorandom permutation |
| : | to |
| : | Pairing operation |
| : | Exponentiation in |
| : | Multiplication in |
| : | Multiplication in |
| : | Addition in . |
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.
Acknowledgment
This work was supported by the IT R & D program of MKE/KEIT (10041244, SmartTV 2.0 Software Platform).