A system model of cloud data group sharing is shown in Fig. 1. The entities in the system are described as below.

Cloud Service Provider (CSP): cloud provides storage service for every group user, and will respond to integrity challenge of data blocks.

Besides the common threat of normal PDP schemes discussed in many works before [11], in this part we focus on the specific threat in user revocation scenario. A user u1 quits its group due to some reason, leaving data blocks {mi} to be transferred to user u2 . Original signatures of these blocks are σi and TPA needs to authenticate the re-signed signatures {σi′} with the help of CSP. In this process, there are two kinds of attack threatening group sharing data auditing:1)

The revoked user may collude with CSP and try to introduce incorrect or even harmful information into re-signed signatures.

Here we omit the common threat such as an external malicious adversary forging signatures, and focus on the discussion of threat in user revocation. Different from previous works [20], we try to loosen the security assumption that CSP and TPA must be semi-trusted. They can be untrusted, just like real entities in real society. The most difficult point to resist collusion attack is that malicious revoked user may leak the secret key of group to TPA or CSP, leading to weakening of group security. Considering the factors above, we propose the following goals necessary for a secure user revocation scheme:

Correctness: A group sharing data PDP scheme holds the property of correctness if and only if for any polynomial adversary, integrity proof cannot pass verification unless it is generated by intact data blocks and signatures.

Denote two multiplicative cyclic groups of prime order q as G1 and G2 , and their generators as g1,g2 respectively. Bilinear map e:G1×G2→GT holds properties as follows:

Bilinearity: for all u∈G1,v∈G2,a,b∈Zq , there holds e(ua,vb)=e(u,v)ab .

Computational Diffie-Hellman Assumption. Consider a cyclic group G of prime order q. Let g be a random generator of G and choose two random elements a,b from Zq . Value of gab is computationally intractable when (g,ga,gb) is given.

Discrete Logarithm Assumption. Given a cyclic group G of order q and any two random elements a,b of G , choosing an integer k∈Zq that solves the equation bk=a is termed a discrete logarithm. If prime number q is a sufficiently large, computing k in polynomial time is hard.

Ring signature is a kind of digital signature cryptography firstly introduced in 2001, which is named after its ring-like structure of algorithm. Ring signature can be performed by any member in a set of users connected by shared keys. When checking validity of ring signature, verifiers can learn whether the signature comes from certain set of users, but cannot reveal the identity of real signer. Ring signature ensures that it is highly computationally infeasible to determine the real signer identity, which makes the scheme well suited for ad hoc group.

Ring signature has high anonymity, which brings another problem: it is quite hard for a user to prove a certain signature is signed by itself without breaking the anonymity. To solve this problem, linkable ring signature is proposed [27]. It enables proving two signatures signed by the same user sharing some kind of link, which is called that these signatures are linked.

Although the first blockchain network is born for cryptocurrency, the progress of technology has already enabled blockchain network to be used for non-financial fields. In this work, we take that advantage and design a blockchain-based group data auditing scheme. We build our work on the basis of a well-known platform, Hyperledger Fabric.

Fabric is a customizable blockchain system, which allows different users join the network and make transactions via installed smart contracts. The workflow of a transaction in Fabric is as below:

Propose: Clients propose requests of transactions to blockchain network.

In this part, we will introduce the basic definition of our proposed group PDP scheme.a)

Setup Phase

KeyGen(1κ)→(sk,pk,param) Let κ be secure length of the proposed scheme. Every user should invoke this algorithm when joining group. And the algorithm will output their private and public keys (sk,pk) as well as common secure parameter param.b)

Preprocessing Phase

SigGen(m,sk,pk)→(σ,L) Denote data block as m. Before uploading m, its owner uo invokes SigGen to choose a ring L and generate signature σ . L is a list of public keys from n members of group, including uo . Thus, the real identity of data owner for m will be hidden in L.c)

Verification Phase

ChalGen({idxi})→(chal) . A group user run this algorithm to generate challenge request chal for TPA. {idxi} are the indices of blocks to be checked, denoted as K indices in total.

ProofGen(chal,{mi})→(P) . When CSP receives challenge request chal , it firstly queries required blocks {mi} in storage, then invokes ProofGen to compute the integrity proof P in response.

ProofVerify(P,σ,L)→(TRUE,FALSE) . Once receiving integrity proof P from CSP, TPA will parse block signature σ and related ring L from blockchain-based ledger. Then it runs algorithm ProofVerify to check the proof. If algorithm accepts, it outputs TRUE ; otherwise, FALSE .d)

Update Phase

Update(m′,sk,pk)→(σ′,L′) . The algorithm of Update is the complement of SigGen , for deleting or adapting data blocks. Data owner invokes this algorithm to upload modified signature σ′ and ring list L′ to CSP.e)

Revocation Phase

ReSig(sk,pk,L,σ)→(L′,σ′) . Before exiting group, the user to be revoked invoke this algorithm to re-sign its data blocks which need to be kept in the group. Each signature σ with ring list L will be recomputed to new one (L′,σ′) .

UsrRevo(pk)→(TRUE,FALSE) . After resigning the blocks, user call this algorithm to inform TPA of formal revocation. TPA checks whether there are omitted blocks not resigned yet, and decides to accept or reject the application.

Different from previous works [22], we use linkable ring signature instead of group signature, in order to obtain anonymous auditing. That is to say, TPA cannot infer the owner identity of challenged blocks, thus our proposed scheme is privacy-preserving.

KeyGen. When initializing a group, choose two be multiplicative cyclic groups of prime order q, denoted as G1 and G2 . Let g1,g2 be their generators respectively, and e:G1×G2→GT be bilinear map. Choose two collision-resistant cryptographic hash functions H1:(0,1)∗→Zq and H2:(0,1)∗→G1 . Pick a random element π←Zq as the private key of group users, then compute common public key ρ=g2π . At this point, the shared keys and public parameter of group have been established.

When a user ui joins group, it should set its own private and public keys as follows:1)

Pick random element xi←Zq as private key.

SigGen. Consider a data owner uj and its data block m to be uploaded. Denote the total number of current members in group as d, and uj extracts n out of d users, generating a ring L=(y1,y2,…,yn),1≤j≤n , where yi is the public key of user ui registered in blockchain network before. A ring signature of block m is generated in the following way:1)

Compute h=H2(L) y~=hxj

Finally, the ring signature for data block m is σ=(c1,s1,…,sn,y~,t) .

ChalGen. In data auditing scheme, there are two cases when choosing block to check. One case is that user wants to check some certain blocks and learn their status. The other is randomly selecting a few blocks for inspection. No matter which case, user choose K blocks with indices (idx1,idx2,…,idxK),K≥1 to be challenged. The procedures follow the steps below:1)

Pick K random elements γk←Zq,1≤k≤K for each block. Assemble a challenge chal={(idxk,γk)}1≤k≤K .

ProofGen. When receive challenge request from blockchain network, CSP generates an aggregated zero-knowledge proof as follows:1)

Pick random element r←Zq and compute R=g2r , in order to masking blocks.

Then send (μ,R) to blockchain network as integrity proof.

ProofVerify. Once receiving proof, TPA check the integrity in the following way:1)

For each data block midxk , refer to its record in distributed ledger and extract corresponding ring Lk={yi,k}1≤k≤K .

for 1≤i≤n−1 , compute zi,k′=g1si,kyi,kc~i,k zi,k′′=hsi,ky~c~i,k c~i+1,k=H1(Lk,y~,zi,k′,zi,k′′)

After that, compute c~1,k=H1(Lk,y~,zn,k′,zn,k′′) 3)

Finally, check the equation(1) e(g1μ⋅∏k=1K⁡c~1,kγidxk,ρ)=e(R⋅∏k=1K⁡tidxkγidxk,g2)

If it holds, accept the proof; otherwise, reject.

Update. In our scheme, the identity of data owner for each block is confidential. So when a user tries to update a block, it must prove itself as the legal owner of targeted block. Our method provides good support for such operation. Considering two valid data tags with blocks (σ,m) and (σ′,m′) , it is easy to construct F1 as judgement of whether σ=(c1,s1,…,sn,y~,t),σ′=(c′1,s1′,…,s′n,y~′,t′) holds y~=y~′ . Since σ,σ′ share the same ring L, y~=y~′=[H2(L)]xj generated by the same user uj must holds.

Modifying. Procedure of modifying a block can be seen as uploading a new block m′ to replace the original m. To prove ownership of original block m, data owner only needs to offer the new tag σ′ for checking whether y~=y~′ holds. In this way, we ensure data sovereignty of owners without adding heavy computation and communication overhead.

ReSig. Considering a block m of user u1 with private key x1 and public y1 , when u1 need to quit from group, it has two choices to dispose m : deleting or re-signing. The deleting case can be classified as that of Update, so here we just introduce the part of re-signing. The process of re-signing is as below:1)

User u1 -negotiates with user u2 and u2 agrees to take over block m.

UsrRevo. After disposing all its blocks, the user to be revoked sends a request to inform the blockchain network. TPA checks its ledger for whether there are still blocks to be dealt with. If all blocks are re-signed or deleted, TPA accepts the revocation. Otherwise, reject.

In order to obtain non-repudiation and collusion-resistant group auditing, we need to wrap the algorithms above into chaincodes to be executed in blockchain network. Due to the mechanism of smart contract endorsement, each phase should be divided into two parts: on-chain transaction and off-chain operation. The on-chain transaction is similar to generating a new blockchain transaction. User or cloud service, acting as client, sends requests to blockchain network. And TPA plays the role of endorsement node, checking the validity of those requests and making decision for whether to accept transactions or not. The off-chain operation, just as it namely implies, is performed by entities locally at their own storage and computing resource, such as generating secret keys, signatures and integrity proofs. The reason for such division is that the operations about random element picking cannot be simulated in endorsement computation, and computing using private key should be secret.a)

Setup Phase

KeyGen. User firstly execute the off-chain operation to generate its own private and public keys. Then it signs a message as the proof of public key and send transaction to blockchain network. TPA checks the validity of public key following method in smart contracts. If the key passes verification, TPA accepts the user to join in the group; otherwise, reject. In this way, we protect the secret of private key for user and make sure that each public key is valid when joining the group. The whole process is shown in Fig. 2. b)

Preprocessing Phase

SigGen. Before uploading data blocks to cloud, data owner executes off-chain operation to generate signatures with private key and ring list. Then the owner sends request to TPA to register these signatures, meanwhile transferring data blocks to cloud storage. The CSP, once receiving the blocks, generates an integrity proof and sends to the blockchain network to check the validity of block signatures. If the proof can pass verification by TPA, CSP and TPA both agree that these signatures are valid and data blocks are intact. Otherwise, they refuse to accept the result and contact data owner for further dealing. The whole process is shown in Fig. 3. c)

Verification Phase

ChalGen. Group user decides challenged block indices and chooses random elements to generate challenge request in off-chain operation. Then it sends the request to blockchain network via on-chain transaction. TPA, working as endorsement node, checks whether the request is from valid user.

ProofGen. Once receiving challenge request, CSP extracts data blocks from its storage and computes integrity proof as off-chain operation. In this way, content of data blocks can avoid to be exposed to TPA in blockchain network. And in on-chain transaction, it sends the proof to blockchain network.

ProofVerify. This algorithm is a full on-chain transaction. TPA verifies the proof and gives result in form of endorsement. The whole process of this phase is shown in Fig. 4. d)

Update Phase

Update. The off-chain operation of this phase is similar to that of Preprocessing. User firstly computes new signature and proof of ownership in the off-chain part, and then sends the information to blockchain network in on-chain part. TPA will check the ownership proof, making sure the validity of updating and accept new signature. The whole process is shown in Fig. 5. e)

Revocation Phase

ReSig. User generates re-signed signatures in the off-chain part, and then sends the request to blockchain network via on-chain transaction. TPA checks validity of re-signing signatures in the endorsement process. Finally, the re-signed signatures will be written into distributed ledger.

UsrRevo. User sends the revocation request as on-chain transaction, and TPA checks its validity according to whether all the signatures of user has been processed. If the user has finished the disposition of its signatures, TPA will accept its revocation and remove its public key from user key list. The whole process of this phase is shown in Fig. 6.

In this part, we will discuss the security properties of our blockchain-based PDP scheme, including correctness, non-repudiation, unforeability and privacy preserving.

Theorem 1. (Correctness) If when most TPAs in blockchain network are honest, an integrity proof from CSP cannot pass the integrity verification unless the cloud holds correct data, we say that the proposed scheme has the property of correctness.

Proof. First of all, as the basis of whole scheme, we will prove that Eq. (1) of ProofVerify holds. With preliminary knowledge introduced before, we deduce the left-hand side of (1) as follows: e(R⋅∏k=1K⁡tidxkγk,g2)=e(g1r⋅∏k=1K⁡(c1,k⋅g1midxk)π⋅γk,g2) =e(∏k=1K⁡c1,kγk⋅g1midxk⋅γk+r,g2π) =e(g1μ⋅∏k=1K⁡c1,kγk,ρ) =e(g1μ⋅∏k=1K⁡c~1,kγk,ρ)

The last step of deduction holds if and only if c~1,k=c1,k,k=1,…,K also holds.

Therefore, we can say that if an integrity proof pass checking in ProofVerify, both the ownership (contained in c1,k ) and content (contained in midxk ) are ensured to be correct.

Theorem 2. (Non-repudiation) If most TPAs in blockchain network are honest, any malicious adversary cannot control the result of integrity verification by in collusion with CSP or data owner.

Proof. We have already proved the correctness of our integrity auditing scheme. Therefore, we can say that if a TPA is honest, it will always give honest decision for proof checking. On the other hand, the extraction of signatures for verification is based on distributed ledger of blockchain network. So even CSP or data owner in collusion with any dishonest adversary, they cannot tamper signatures used for verification. An honest TPA can always draw correct result. Also, blockchain network is believed to resist history attack, so we can say that our scheme can resist attacking from minor malicious adversary.

Theorem 3. (Unforgeability) For any user or CSP, forging signature of another member is infeasible in polynomial time if and only if the DL assumption holds.

Proof. Let L=(y1,y2,…,yn) be a given ring of n group users. Assume a PPT adversary A , able to make at most qH times of queries to hash functions H1 and H2 as well as qS times to RSO , can forge ring signature σ with non-negligible probability as Pr[A(L)→(m,σ):V(L,m,σ)=1]>1Q(k) where Q is polynomial and k is the security parameter. RSO is a ring signature oracle which returns valid LHARS signatures upon queries of A .

Now we assume that A constructs a PPT simulator M to generate forged signature. Since π←Zq,ρ=g2π are the common keys shared by group members, we suppose that M holds (π,ρ) and simplify the problem as follows.

Ring Signing Oracle: Given any data block m, any public key list L=(y1,y2,…,yn) , the ring signing oracle RSO generate a signature. M simulates RSO to generate a signature without holding any secret keys of individual group members.

Without loss of generality, we assume that M randomly picks r←Zq and queries hash function to get h=H2(L) . Then compute y~=hr and chooses c1,…,cn,s1,…,sn . Back patch to ci+1=H1(L,y~,g1siyici,hsiy~ci),1≠i≠n,n+1→1

Eventually A successfully forges (c1,…,cn,s1,…,sn,y~) and M performs rewind-simulation to generate (c′1,s1′,…,s′n,y~) . Denote the forgery signer of A is $j$, then M can obtain xj as follows: cj+1=H1(L,y~,g1sjyjcj,hsjy~cj) c′j+1=H1(L,y~,g1sj′yjcj′yjcj′,hsj′y~cj′)

Remember y~=hr , then sj+cjxj=sj′+cj′xj sj+cjr=sj′+cj′r

Solve and obtain xj=sj−sj′cj−cj′

According to [27], the probability of M to achieve a solution is at least (1/[n(qH+nqS)Q(k)])2 , which is non-negligible. Therefore, once A is able to forge signature with an advantage of 1/Q(k) , M is able to solve Co-CDH problem with an advantage of (1/[n(qH+nqS)Q(k)])2 . Desired contradiction. Theorem is proved.

Theorem 4. (Privacy Preserving) If and only if DDHP (Decisional Diffie-Hellman Problem) is hard, in the random oracle model, the probability of distinguishing signer of an LHARS signature is at most 1/n , where n is the size of ring list L.

Proof. For any g1,h∈G1 , and 1≤j≤n , the distribution of (c1,…,cn,s1,…,sn) is identical. Therefore, the probability of a PPT adversary A to distinguish cj,sj from (c1,…,cn,s1,…,sn) , in order to point out the signer uj , is at most 1/n . Reference [27] gives further detailed explanation.

Our proposal is a comprehensive solution for group data integrity auditing, including improvement on both security and efficiency. First of all, we compare the security features of our proposal with other comparable solutions, shown in Tab. 1.

To evaluate the practical performance of our scheme, we deploy an instance of our proposed scheme on virtual private server (VPS), which has 1 CPU, 2GB memory and 2TB bandwidth. The server has installed the open source blockchain platform Hyperledger Fabric and we implemented chaincode for our scheme based on Fabric SDK for JAVA. Fabric offers necessary membership services, certificate authority management, consensus plugin and customizable endorsement policies, thus we can focus on implementing our scheme itself.

In our instance, the on-chain operations are wrapped as smart contracts, while off-chain algorithms are implemented in the form of local scripts, both written in Node.js. Entities in our scheme execute their local scripts to complete the off-chain computation and invoke smart contracts to finished the on-chain parts. In this way, we realize the separation of on-chain and off-chain parts.

Choosing a secure length of 1024 bit, time for the off-chain part of generating signature is shown in Fig. 7. We deploy two patterns of our proposal--original and simplified ones. For one file divided into blocks, an intuitive way to reduce computational overhead and storage cost is using the same ring for all the blocks, which will not compromise the security, called ‘’simplified’’. We also implement a few comparable works under the same security length, in order to present efficiency of our proposal.

As the size of ring length grows, time of generating signature for data owner increases from 10.07 ms per block to 39.36 ms for our original proposal, as well as from 5.39 to 6.16 ms for simplified mode. However, previous works cost much more time to generate signatures. The main reason is that Knox needs to compute more modular exponential operations and Oruta has complex progress of group signature computation. Work of Jiang et al. [21] has the same signing algorithms with those of Knox, and will undoubtedly suffer from the heavy overhead of modular exponentiation. The result also suggests that choosing a reasonable size of ring, computation overhead of our proposal for data owner is very low.

Under the same secure length mentioned above, we also measure the time cost of re-signing signature for the new data owner, as shown in Fig. 8. The time cost varies from 0.19 to 0.84 ms per block along with the increasing of ring length. Comparing to generating signature, the computation overhead of re-signing is relatively much lower, which also shows the efficiency of our scheme.

To evaluate the performance of on-chain operations in blockchain network, we also perform smart contracts in VPS. We employ the benchmark test tool Hyperledger Caliper, which enables users to write the test and network configuration, launching an instance and executing required smart contracts defined in given chaincode automatically. We execute 7 rounds of test, 100 times per round. Each round the proportion of challenged blocks varies from 1%, 10%, 20%, 40% to 100%. Since the verification is the most expensive part for endorsement peer (TPA), we choose it as the test chaincode. Fig. 9 shows the indicators of efficiency for each round. The figure suggests that each round does not show a huge difference in verification. The possible reason is that we use an aggregated proof, thus the main cost of such verification lies in the computation of bilinear mapping. It also proves that our scheme has a relatively smooth performance in on-chain operation.