Incentive Public Auditing Scheme with Identity-Based Designated Verifier in Cloud

Abstract

With the rapid development of cloud storage and cloud computing technology, users can upload data to the cloud and share it with other users. However, the integrity and the privacy of data files at the cloud service provider suffer from challenges. In order to protect the data of user in the cloud, particularly for user groups without honest managers and semitrusted third-party auditors, we construct a new public auditing scheme that integrates a $(t,n)$ threshold signature, an incentive mechanism, an identity-based designated verifier group, blinding technology, and a multiblock signature technique. In our scheme, the $(t,n)$ threshold signature can eliminate the single power of the user group’s managers, to ensure that members of the user group take part in data sharing fairly and equally. The generation of a user’s key pairs and the signatures of data can be encouraged by an incentive mechanism based on a blockchain. Moreover, we introduce an identity-based designated verifier group and blinding technology to preserve data privacy during the data integrity auditing process. Furthermore, the multiblock signature technique reduces the costs to sign data blocks and verify. Finally, the security analysis and performance analysis demonstrate that our scheme is provably reliable and efficient.

1. Introduction

With the widespread application of Internet technology and cloud computing technology [1], increasingly, cloud service providers (Apple iCloud, Google App Engine, BaiDu Cloud, Ali Cloud, etc.) can provide data storage services for users or organizations. Therefore, to decrease the overhead of data storage and management, more and more users and organizations select to lease a cloud service provider (CSP) to reserve their data [2]. Moreover, the cloud makes it easier for data owners to form a user group (UG) to store and share their outsourced data files across devices and locations.

However, in order to ensure that data owners of a UG can share data information with other members fairly and equally, it is necessary to solve the problem that users cannot participate in data sharing equally due to the concentration of power of the user group’s managers [3]. In addition, if members of a UG already have equal rights to share data, the low enthusiasm and low efficiency issue when uploading shared data cannot be ignored [4]. In short, under the premise of ensuring the integrity of data in the CSP, the problem of a centralized management authority needs to be solved, and the enthusiasm of users to upload data to a CSP needs to be improved.

After users store their outsourced data files to the CSP, the integrity and the privacy of the data files in the cloud are under threat [5]. On the one hand, the data uploaded to the CSP can easily be damaged or deleted by hardware failures, software exceptions, and human factors. On the other hand, the outsourced data file in the CSP maybe be corrupted and stolen by a half-honest cloud service [6]. As users lose direct control of their data, they cannot be sure that their data files stored in the cloud are complete [7]. Therefore, an effective method to check the integrity of data in the cloud without downloading them is required [8].

In particular, users are desperate for a scheme to help them check the integrity of their data. According to the methods of a data integrity audit, an audit is divided into two types: a private audit scheme [9] and a public audit scheme [10]. In a private auditing scheme, the auditor is the data owner themselves. On the contrary, in a public auditing scheme, anyone can play the role of validator to perform the audit task. So far, many specific schemes have been proposed for different systems under different models [3,4,8].

In order to improve the reliability and efficiency of the data integrity audit process, most methods employ a public auditing scheme that outsources the audit work to third-party professional verifiers. Therefore, a public audit is very common in concrete applications. However, third-party verifiers may intentionally or unintentionally access users’ private data information during the audit process [11,12,13,14]. Under this situation, some researchers have proposed many new privacy-preserving schemes [15,16,17,18]. Specifically, users of a cloud service require and wish to constrain the auditor’s identity, allowing only a designated verifier to check the integrity of the data stored at the CSP.

To our knowledge, most traditional public data-auditing schemes rely extensively on public-key cryptography [12,13,14,15,16,18,19]. Moreover, these schemes request a credible certificate authority center to generate verifiers’ certificates by binding their identities and the associated public–private key pairs. With the increase of the number of users, a certificate authority center needs to generate and distribute a large number of certificates to many verifiers in the designated verifier group (DVG). Therefore, the certificate management becomes more complex, including for the generation, storage, delivery, and update of certificates, which causes increasing additional communication costs and computational costs and also greatly reduces the efficiencies of the public audit protocols.

To avoid having the certificate authority center based on public-key cryptography, in 1984, Shamir presented the notion of identity-based cryptography [20]. Specifically, for a public verifier based on identity-based cryptography, the members of the DVG choose their verifier’s identifiers, including an ID-card number, email address etc., as their verifier’s public key. Additionally, the corresponding secret key of a designated verifier is generated by the mutual cooperation between the verifier’s public key based on identity information and a private key generation center called a key generation center (KGC) [21]. Therefore, proposing a public audit scheme for an identity-based designated verifier is a trusty way to audit the security and integrity of data files at the CSP.

The main problems mentioned above can be generalized into the following four points. Firstly, when the users of a UG upload data to the CSP, to eliminate the problem of the centralized management powers of the user group’s managers, a $(t,n)$ threshold signature [3,22] is used to enable the user group members to participate in data sharing with equal and fair rights. Moreover, the signers of the UG sign multiple data blocks together via a multiblock signature technique. Secondly, with the elimination of user group managers, users of the UG may be inefficient when participating in the process of generating key pairs and signing data blocks. Therefore, a blockchain-based incentive mechanism [4,23] is put forward to improve the generation efficiency. The blockchain has three merits, including decentralization, tamper-resistance, and traceability [24], where decentralization offers users a fair environment, tamper-resistance ensures that a user’s records are correct and trustworthy, and traceability can verify the recording history for users. Thirdly, after users store data at the CSP, their integrity and privacy can be compromised by a semihonest cloud. Thus, verifiers are needed to verify the integrity of the data files at the CSP. In our scheme, an identity-based designated verifier is proposed to check data files at the CSP [25]. Lastly, when the member of the DVG audits the data in the CSP, the data are blinded through data-blinding technology to avoid the problem of the data information being stolen by malicious hackers.

1.1. Contributions

In our paper, we constructed an incentive public auditing scheme with an identify-based designated verifier at the CSP. We summarize the main contributions of the body text as follows.

1.1.1. Contribution 1

In the data integrity audit stage, the verifier may be curious and steal the data stored by the user. Therefore, in the public audit scheme of this paper, professional third-party auditors are designated by members of the user group, so as to determine the identity of auditors, enhance the integrity of auditors, and reduce the risk of data privacy disclosure. In addition, the third-party auditor is not a single validator, and the improved designated verifier group is composed of multiple auditors designated by the user group members, so as to avoid new difficulties caused by the failure of the public audit scheme when the single designated validator fails.

1.1.2. Contribution 2

The key-pair generation scheme of the designated verifier group, which is specified by the user, is completely generated by the traditional PKI-based certificate authority (CA), and improved compared to the identity-based verifier based on IBC. The key pair of the authentication group is based on the identity information. The KGC generates a key pair based on the identity information of the authentication group. On the one hand, it effectively reduces the overhead cost of the certificate authority; on the other hand, the security of the key pair of the authentication group is enhanced.

1.1.3. Contribution 3

In this data file’s block signature, a multiblock signature technology is introduced. Specifically, the data-file block-signature technology uses a matrix mathematical form, where the data file is divided into multiple matrix file blocks. After the data are partitioned, QU members in the user group (UG) sign multiple data blocks in a certain form. Compared with the paper [4], the same unblocked data file is signed by multiple qualified users. The advantage of this scheme is that the overhead cost is reduced.

1.2. Related Work

Because the public verifier may be curious about the information in the data files in the cloud, it may attempt to steal sensitive user information from the messages received during the audit. Therefore, the public audit scheme needs to solve this privacy protection problem. In 2007, a scheme of traditional cryptography proposed by G. Ateniese et al. [26] could not be used for the integrity audit of data in the cloud. Thus, to address this confusion, H. Shacham et al. [10] first proposed the concept of public audit in 2013. They came up with the first scheme of cloud audit, which checked the integrity of users’ data stored in the cloud. In order to improve performance and safety, many public auditing schemes based on public-key cryptography [12,13,14,15,16,18,19] have been proposed. In these schemes, a certificate authority center is responsible for the certificate’s distribution and storage. However, as the number of users keeps climbing, it also increases the cost burden more and more.

In 1984, the concept of identity-based public-key cryptography was put forward by A. Shamir [20], which addressed the problem of certificate management dependent on public-key cryptography. In 2014, a public cloud auditing scheme based on identity-based public-key cryptography was put forward by H. Wang et al. [27], who demonstrated that the scheme had a proven safety. In 2017, Y. Wu et al. [28] proposed a secure IB-PDP protocol with perfect data-privacy-preserving characteristics. In 2019, an identity-based public auditing protocol against malicious auditors based on the blockchain was put forward by J. Xue et al. [29]. Moreover, a new identity-based data storage protocol was also put forward by J. Li et al. [30], which used a homomorphic verifiable tag to decrease the system complexity in 2019. Later, J. Li et al. [17] proposed a cloud auditing scheme based on identity-based public-key cryptography which preserved data privacy against a third-party audit in 2020. Recently, in 2020, H. Yan et al. [18] proposed an efficient designated-verifier provable-data-possession protocol, where the data owner specified a designated verifier to check the integrity of their data in the cloud.

In addition to considering data privacy issues during public audits, we also need to ensure data integrity and security during data sharing among multiple users and uploading to the cloud for storage. In 2014, a provable-data-possession-based mechanism was put forward by Wang et al. [8], Oruta, which could perform public audits of data shared in the cloud. Later, in 2019, H. Wang et al. [23] pointed out that Oruta could calculate the authentication information used to audit the integrity of the shared data from the data in the audit process but could not resist group member change attacks. Thus, a new scheme called IAID-PDP [23] was put forward by these authors that could not only resist group user change attacks but also rewarded the crime reporter. However, because of the use of a ring signature, the audit time of Oruta [8] and IAID-PDP [23] increased rapidly with the number of users in a user group. As a result, the scheme could not audit data shared by a large number of users.

To solve the problem caused by the ring signature, Wang B [15] proposed a scheme called Knox where the group signature was used to construct homomorphic authenticators, and the number of user group members did not affect the audit time. However, since the permissions of the group manager scheme, Knox [15], were higher than the permissions of the users, it could not support a public audit and adapt to equal user member groups. Thus, in order to ensure the fairness and equality of group users, Fu A et al. [3] proposed the NPP scheme by using a $(\mathit{t},\mathit{n})$ threshold signature, where the power was shared among multiple managers to eliminate power abuse caused by a single manager’s power.

Additionally, in 2020, Huang L et al. [4] adopted the $(\mathit{t},\mathit{n})$ threshold signature that not only realized a public audit but also allowed $\mathit{n}$ user group members to equally participate in the generation of the valid signatures of files. Since the users of a user group can equally participate in generating key pairs and data block signatures, users may be inactive and inefficient. To increase efficiency, these authors introduced the incentive mechanism [23] in their paper [4]. The incentive mechanism encouraged members of a user group to participate in the generation of file signatures by rewarding the user who generated qualified signatures first through blockchain technology [24]. In 2019, J. Li [31] proved that based on the characteristics of the incentive mechanism based on blockchain technology, users were encouraged to participate in the forwarding and receiving of data packets, encouraging them to get corresponding rewards.

1.3. Organization

The rest of this article is organized as follows: In Section 2, we present preliminary knowledge. In Section 3, we present our system model and an overview of our proposal. The construction of a detailed scheme is introduced in Section 4. Section 5 shows the security analysis. The performance of our scheme is analyzed in Section 6. At last, we summarize our study in Section 7.

2. Preliminaries

Before presenting the details of our design proposal, we present the preliminary knowledge utilized in the article.

First, we list some symbols that appear in our paper and their definitions, as shown in

Table 1. Symbols and their definitions.

Symbols	Definitions
UG	User group
CSP	Cloud service provider
DVG	Designated verifier group
KGC	Key generation center
$G_1,G_2$	Cyclic groups
q	The prime order of ${\mathit{G}}_1,{\mathit{G}}_2$
g	The generator of ${\mathit{G}}_1$
e	Bilinear map from ${\mathit{G}}_1$ × ${\mathit{G}}_1$ to ${\mathit{G}}_2$
$H,H_1,H_2,H_3$	Hash function
f	Pseudorandom function
$\pi$	Pseudorandom permutation
$VID$	The identity of DVG
$f_i\left(x\right)$	Random polynomial function
$s{k}_{ui},p{k}_{ui}$	User’s shared key pair
$s{k}_u,p{k}_u$	User group key pair
$s{k}_v,p{k}_v$	The key pair of DVG
M	Outsourced file
$m_b$	Outsourced file block ${\mathit{m}}_{\mathit{ab}, 1\le \mathit{a}\le \mathit{l}}$
$S_{ib}$	The partial signature of ${\mathit{m}}_{\mathit{b}}$
${\lambda }_{\mathit{i}}$	A Lagrangian interpolation coefficient
$S_b$	The final signature of ${\mathit{m}}_{\mathit{b}}$
$N_b$	The number of ${\mathit{m}}_{\mathit{b}}$ identifier
$chal$	Challenge message
c	The number of challenged blocks
$pro$	The audit proof
$coin$	Total incentive fee
$S{e}_b$	Sequence number of a valid signer
$U_{icoin}$	The incentive fee of a valid contributor

.

2.1. Bilinear Map

Definition: $G_1$, $G_2$ are two multiplicative cyclic groups with the same large prime order $q,g$ being a generator of $G_1$. Let $e:G_1\times G_1\to G_2$ be a bilinear map, with the following attributes.

2.1.1. Computability

For $u,v\in G_1$, there exists an efficient algorithm to compute the map $e(u,v)$.

2.1.2. Bilinearity

For $u,v\in G_1$ and any prime $a,b\in Z_q^{*}$, the equation $e(u^a,v^b)=e{(u,v)}^{ab}$ holds, where $Z_q^{*}$ is the set of prime numbers.

2.1.3. Nondegeneracy

There must be a way to efficiently compute the bilinear map e in the form $e(g,g)\ne 1$.

2.2. Complexity Assumption

Definition 1

(CDH problem). Given $G_1$ as a multiplicative cyclic group and g a generator of $G_1$, define the tuple $(g,g^a,g^b$) with the unknown elements $a,b\in Z_q^{*}$; the CDH problem is to compute $g^{ab}$.

Definition 2

(CDH assumption). The CDH assumption depends on the CDH problem and is defined as: Let $g,g^a,g^{ab}\in G_1$ be the inputs, where $a,b\in Z_q^{*}$ are unknown, and $g^a$ are outputs. The CDH assumption states that for any probabilistic polynomial time algorithm A, the probability of utilizing A to address the CDH problem is ignorable by Equation (1). Moreover, ϵ represents an ignorable value.

$$Ad{v}_A^{CDH}=Pr[A(g,g^a,g^b)=g^{ab}:a,b\stackrel{R}{\leftarrow }{Z}_q^{*}]\le ϵ$$

(1)

2.3. Identity-Based Verifier

In an identity-based verification agency [17], identities such as an e-mail address, the number of an ID card or a phone number are utilized to produce public and secret keys with a master key owned by an agency called a key generation center. The detailed description of the generation operation is as follows. Firstly, our system selects a security value to calculate the master secret key of the key generation center. Then, given a hash function and the unique identification ID of the verifying agency, it generates a public–secret key pair. Finally, the user group can adopt an identity-based verifier as a user’s designated verifier part.

2.4. (t, n) Threshold Signature

The signer group is made up of multiple signers [22]. Any t or more qualified signers in a user group can cooperate with each other to generate a valid final signature group, but less than t signers cannot generate a final signature group. In addition, only the designated verifier who knows the public key associated with the signer group verifies the correctness of the final signature. In the event of a problem or if necessary, the signer group can certify to a third-party auditor that the final signature is effective under the signer group’s public key. The following describes the process of the $(t,n)$ threshold signature [3]. First, all users, with the help of the user group, generate their shared public–secret key pair using a random polynomial function. Then, the user who generated a valid shared key pair is allowed to produce a shared signature. Lastly, t valid shared signatures are collected and utilized to aggregate the final signature of the data block.

2.5. Blinding Technology

In order to protect the privacy of the data in the cloud, auditors can use blinding technology to blind the data information. The blinding technique comes from a blind signature, a type of digital signature in which the data information is blinded before the signature [4]. The concept of blind signature is to blindly transmit data information using a randomly selected blinding factor. The specific blinding operation is introduced as follows. Firstly, the verifier chooses a new random value v and transmits that value to the CSP to avoid the cloud utilizing the previously transmitted information to pass the integrity verification [8]. Secondly, in order to ensure that auditors cannot steal users’ private information from the data information $vm$ obtained in the audit process, the cloud further selects a random parameter r and blinds data messages through Equation (2).

$$m^{*}=vm+r$$

(2)

Finally, because the original data information m is transformed into $m^{*}$ through the blinding operation, the privacy of user data is enhanced in the audit process.

2.6. Homomorphic Verifiable Tags

The homomorphic verifiable tag [15] (homomorphic validator), which allows auditors to check data integrity without downloading all data blocks, is an essential tool for building public auditing schemes. The homomorphic verifiable tags based on signatures should include the attributes of unforgeability, blockless verification, and nonmalleability. Assume that $(pk,sk$) represents the public key pair of the signer and ${\sigma }_1,{\sigma }_2$ represent the signatures on data blocks $m_1,m_2\in Z_q$. The three attributes of the homomorphic verifiable tags are specifically described as follows.

2.6.1. Unforgeability

Only users with the valid secret keys can produce effective signatures.

2.6.2. Blockless Verification

Auditors can verify the integrity of data files at the CSP by a linear combination of data blocks without downloading all the data. Specifically, given two random numbers ${\sigma }_1,{\sigma }_2\in Z_q$ and a linear combined data block $m^{\prime }={\sigma }_1{m}_1+{\sigma }_2{m}_2\in Z_q$, the verifier can audit the integrity of the linear combined block $m^{\prime }$ without knowing the data blocks $m_1,m_2$.

2.6.3. Nonmalleability

The member of a user group without the effective secret key cannot produce an effective signature on the combined block by utilizing the given data signatures. To be specific, given two random values ${\sigma }_1,{\sigma }_2\in Z_q$ and a linear combined data block $m^{\prime }={\sigma }_1{m}_1+{\sigma }_2{m}_2\in Z_q$, if the user does not have an effective secret key, they cannot produce an effective signature ${\sigma }^{\prime }$ by combining ${\sigma }_1,{\sigma }_2$.

3. System Model and Design Scheme

We present the scheme model in this proposal, including the system model, overview of the scheme, and security model.

3.1. System Model

In this paper, the system model of our proposal consists of four institutions: a user group (UG), a cloud service provider (CSP), a designated verifier group (DVG), and a key generation center (KGC); the specific definitions are as follows.

3.1.1. User Group

The user group contains $\mathit{n}$ users. In essence, in the data integrity scheme, each user in the user group can upload their data files to the cloud, that is, the user is the data owner in the cloud. Similarly, every member of the user group UG can store their data files to the cloud service, so every user in the user group can be the data owner. They rent the CSP and upload data files to the CSP. Users can ask the DVG to audit their data files in the CSP. It creates a data access request to the CSP, and the cloud will respond with the data and associated integrity proofs.

3.1.2. Cloud Service Provider

The CSP has a huge storage ability and strong computing power. It provides storage services to the UG and sends the integrity proof of data files back to the DVG when the cloud accepts a data integrity challenge request.

3.1.3. Designated Verifier Group

The members of the DVG are requested by the UG to be the public checking verifier to audit user data at the CSP. The DVG consists of multiple designated verifiers. A designated verifier of the DVG will regularly verify the data integrity at the CSP. The DVG performs an integrity audit on all data stored at the CSP, as opposed to users only verifying the data they access. In private auditing schemes, auditors are generally verified by the data owner themselves (the user) rather than by third-party auditors. Since the data in the cloud are where the data ownership is stored, there is no need to worry about invisibility in the data integrity audit process in private audit solutions. However, the public auditing scheme in our scheme needs to perform an integrity verification with privacy protection.

3.1.4. Key Generation Center

The KGC is responsible for producing the key for the designated verifier of the DVG. With the identity-checking agency, the KGC computes the key and sends it to the DVG in a safe way.

Figure 1 displays the connections and interactions between the four bodies of the system model of our scheme. It was assumed that the CSP was half-honest; in other words, it sent back one response per challenge request but could trick the DVG on data-corruption events to maintain its reputation. Moreover, the DVG was truthful but curious. It honestly performed data integrity auditing and sent true results back to the data owner. However, the members of the DVG were curious about the user’s privacy information and attempted to obtain these data when performing data integrity auditing.

3.2. Overview of Our Scheme

The proposal in our article consists of the nine algorithms described below.

3.2.1. Set Up (1${}^{\lambda }$)→(params, msk)

This algorithm is executed by the system. It inputs the security parameters $\lambda$ and outputs some common parameters $params$ and the master key $msk$. The purpose of this algorithmic step is to generate initialization and public parameters for the entire data integrity audit scenario. The parameters generated in $params$ are public parameters and participate in subsequent algorithm steps, including the key-pair generation algorithm, signature generation algorithm, and public audit algorithm. In addition, the $msk$ generated by the KGC in this algorithm step is the public parameter of the subsequent key algorithm that generates the specified verifier.

3.2.2. Designated Verifier Extract ($msk,VID$)→(${sk}_v,p{k}_v$)

The algorithm is performed by the KGC to produce a key pair of the designated verifier group. It inputs the master secret key $msk$ and the identity of the DVG $VID$ and outputs the designated verifier’s secret key $s{k}_v$ and public key $p{k}_v$.

The designated verifier group is composed of multiple third-party auditors designated by the user. On the one hand, because the verifier is designated by the user, it determines the identity information of the verifier and enhances the privacy of the user data in the process of public audit. On the other hand, multiple validators can avoid the disadvantages brought by a single auditor. Specifically, if the public audit scheme is composed of a single auditor, the whole public audit scheme will not be able to proceed normally once the auditor has problems. Therefore, the verifier members specified in this scenario share the same key pair.

3.2.3. User Key Generation ($f_i\left(x\right))$→(sk${}_{ui},p{k}_{ui}$)($s{k}_u,p{k}_u$)

This algorithm is executed by the UG. It inputs some random polynomial functions $f_i\left(x\right)$ and outputs each user’s shared secret–public key pair (s$k_{ui},p{k}_{ui}$) and user group key pair ($s{k}_u,p{k}_u$).

This algorithm is a key-pair generation algorithm based on the $(t,n)$ threshold signature. Its idea is that UG members cooperate with each other to produce user key pairs, and users who generate qualified key pairs are regarded as qualified user group members. Each QU member of a qualified users’ group is a UG member of the user group. However, each UG member of a user group may not be a QU member.

3.2.4. Shared Signature Generation (sk${}_{ui}$, $\alpha$, VID, $m_b$, $N_b$)→($S_{ib}$)

This algorithm is performed by the UG to produce a set of verification metadata files. It takes a user’s secret $s{k}_{ui}$, extracts the designated verifier group $p{k}_v,$ the identity of the DVG $VID$, the outsourced file block $m_b$, and the number of file block identifier $N_b$ as inputs, and outputs the shared signature $S_{ib}$ of file block $m_b$ by the user $u_i$.

3.2.5. Shared Signature Aggregation ($S_{ib}$, ${\lambda }_i$)→($S_b$)

This algorithm is executed by the UG to aggregate different shared signatures. It inputs multiple different shared signatures $S_{ib}$ of the file block by multiple users and the Lagrangian interpolation coefficient ${\lambda }_i$ and outputs final signature $S_b$.

3.2.6. Challenge (c, $k_1,k_2$)→($chal$)

This algorithm is performed by the DVG to initiate a data integrity challenge. It inputs the number of challenged data blocks c and two random values $k_1,k_2$ and outputs $chal$ as the challenge message.

3.2.7. Proof Generation ($\psi$, $r, chal$)→($pro$)

This algorithm is performed by the CSP to generate data possession proof. It inputs the corresponding blocks’ tags $\psi$, blinding factor r, and a challenging set $chal$ and outputs audit proof $pro$.

3.2.8. Designated Verifier Verification $(s{k}_v, p{k}_u, chal, pro$)→$(0,1)$

This algorithm is performed by the DVG to check the proof message. Given the designated verifier’s secret key ${sk}_v$, public key of the UG $p{k}_u$, the challenging set chal, and the final audit proof pro as input, if pro passed the verification of the designated verifier group, it outputs 1 and 0 otherwise.

3.2.9. Incentive Mechanism ($coin, s{e}_b, N_b, p{k}_{ui}$)→($U_{icoin}$)

This algorithm is executed by the system to perform the incentive mechanism. It inputs the total incentive compensation coin, the sequence number $s{e}_b$, the file block identifier $N_b$, and the public key of each qualified user $p{k}_{ui}$ and outputs the contributor’s fee $U_{i}coin$.

3.3. Security Model

In this subsection, we introduce the security model of our proposal. A data integrity audit mainly faces two threats: data integrity threat and data privacy threat. Data integrity threat refers to the possibility of active attacks (deletion, forgery, etc.) and passive attacks (hacker attacks, etc.) on users’ data stored in the cloud. The threat to data privacy indicates that when third-party auditors check the data in the cloud, they may steal and monitor the users due to their curiosity about the data information, so that the users’ data privacy is threatened. There are two possible threats to data files stored at the CSP. One of the threats is data integrity threats from the CSP, another is data privacy threats during a public auditing process. The specific descriptions of these threats are as follows.

3.3.1. Data Integrity Threat

Users store their data files at the CSP and remove local data files. The outsourced data files stored at the CSP may be damaged by both active and passive attacks. Active attacks are those where an attacker may attempt to compromise the integrity of the shared data, making users use improper data. Passive attacks are when the CSP inadvertently damages (or even deletes) data in their storage due to hardware errors and human factors. Worse, cloud storage providers may withhold information about such data corruption in order to preserve their reputation.

3.3.2. Data Privacy Threat

When a user sends a request to an auditor, the data files stored at the CSP need to be audited by the verifier. Since the verifier may try to obtain data files or some other sensitive information from the received auditing message, the data files stored at the CSP will suffer from data privacy threats. Therefore, data may be leaked to auditors during this public audit.

To avoid integrity and privacy threats to data stored at the CSP, our proposal requires the following security and performance requirements to be achieved.

3.3.3. Correctness

A user group that generates correct shared public keys, correct shared signatures, and correct final signatures can validly pass the verifier’s audit.

3.3.4. Robustness

In the generation of the signature, the system can partially endure the participation of inactive or dishonest signers.

3.3.5. Homomorphic Authentication

A homomorphic authenticator is the foundation for realizing public auditing [15], which needs to satisfy the attributes of blockless verifiability and nonmalleability. Homomorphic authentication is one of the public auditing schemes proposed based on homomorphic verifiable tags, which are the basis of data integrity auditing. In a public audit, auditors do not need to download all the data blocks stored in the cloud but only need to verify some data blocks.

3.3.6. Public Auditing

The verifier can verify the integrity of the data files stored at the CSP without getting the secret key of the user group and verifying all the data.

3.3.7. Unforgeability

It is absolutely impossible for a semihonest cloud storage provider to generate a fake verified audit proof. In other words, only qualified users with the correct shared key can produce signatures for data blocks.

3.3.8. Data Privacy

When a verifier audits data file blocks, they cannot obtain any private information about a user’s data in the process.

4. Our Construction

In this section, we describe the specific structure of our proposal, which supports both public validation and data privacy protection. Furthermore, Figure 2 shows a signature generation model including user key generation, shared signature generation, and shared signature aggregation. Normal users are all members of the user group (UG), that is, the total number of members in the user group whose signature is n in the $(t,n)$ threshold. A qualified user is a member of a user group that generates a qualified user key pair based on a pseudorandom function and user broadcast. A qualified user group (QU) member must be a member of the user group, but not all n user group members must be qualified user group members. In addition, the number of qualified user group members should be at least t users generating the correct user key pair, otherwise the signature model based on the $(t,n)$ threshold signature cannot be carried out. The process of the final signature generation model is as follows. Firstly, all users in the UG can participate in the generation of user keys. In the process, each user who participates in and contributes to the key generation by producing valid shared keys is chosen as a member of the qualified users’ group $QU$ to produce the user’s secret shared keys for all members of the UG. Secondly, all users can produce a shared signatures on the data blocks after obtaining their secret shared key. Any t signers that generate the shared signature constitute a signature group $SG$. Finally, the aggregator chooses a group of signers $SG$ and utilizes their shared signature to produce the final signature. Now, we present the structure of the nine algorithms as follows.

Set Up (1${}^{\lambda }$)$\to (params,msk)$: This algorithm produces the system parameters $params$ and the KGC’s master secret key $msk$ when setting the security parameter $1^{\lambda }$. At first, it randomly chooses a big prime q and two cyclic groups $G_1,G_2$ with the same prime order q. g is a generator of $G_1$. e is a bilinear map of $G_1$ × $G_1$→$G_2$. $H,H_1,H_2,H_3$ are hash functions, which are defined as $H:{\{0,1\}}^{*}\to G_1$ and $H_1,H_2,H_3:{\{0,1\}}^{*}\to Z_q^{*}$. Moreover, it defines $f:Z_q^{*}$ × $\left\{1,2,...,n\right\}$→$Z_q^{*}$ as a pseudorandom function and $\pi :Z_q^{*}$ × $\left\{1,2,...,n\right\}$→$Z_q^{*}$ as a pseudorandom permutation, respectively. Then, the KGC selects a random number $msk\in Z_q^{*}$ as the master secret key. Finally, it sets $params=(G_1,G_2,q,g,e,H,H_1,H_2,H_3,f,\pi )$.

$DesignatedVerifierExtract$ $(msk,VID)$→$({sk}_v, p{k}_v)$: This is a key-pair generating algorithm for the designated verifier group with identity $VID$. When the KGC receives the identity of DVG $VID$, it calculates $s{k}_v=H_1{\left(VID\right)}^{msk}$ as the secret key of the DVG and $p{k}_v=g^{s{k}_v}$ as the public key of the DVG.

$UserKeyGeneration$ ($f_i\left(x\right))$→(sk${}_{ui}$, $p{k}_{ui})(s{k}_u, p{k}_u)$: With the help of all users, this algorithm generates the secret shared key $s{k}_{ui}$, the public shared key pk${}_{ui}$ of each member of UG $U_i$ and the key pair of user group $s{k}_u, p{k}_u$. It should be noted that not every user in the user group demands to take part in the entire process of producing the public shared key and the secret shared value, but a qualified users’ group is composed of t qualified users. The t qualified users are completely honest. Therefore, our scheme can ignore mistakes caused by users when producing a shared key pair.

The generation process for these two key pairs is shown below.

• $\mathit{Generate}{\mathit{sk}}_{\mathit{ui}}\mathit{and}{\mathit{sk}}_{\mathit{u}}.$ First of all, we should define the qualified users. Firstly, every user of UG ${\mathit{U}}_{\mathit{i}}$ chooses a random polynomial function $f_i\left(x\right)=a_{i0}+a_{i1}x+\cdots +a_{i(t-1)}{x}^{t-1}$, where $a_{ik}(1\le i\le n,0\le k\le t-1)$ is a coefficient. Secondly, the user $U_i$ broadcasts variable $C_{ik}(C_{ik}=g^{a_{ik}})$ to all other users, computes the secret shared value $s_{ij}(s_{ij}=f_i\left(j\right))$, and transmits the value $s_{ij}$ to user $U_j$($j\ne i$) safely. After getting $s_{ij}$ from user $U_i$, user $U_j$ checks the justifiability of $s_{ij}$ by Equation (3).

  $$g^{s_{ij}}=\prod _{k=0}^{t-1}\left(C_{ik}\right)j^k,1\le i,j\le n$$

  (3)
  If the result of Equations (1) and (3) is not equal, this indicates that the secret shared key is wrong. Thus, user $U_i$ cannot become a qualified user. Moreover, user $U_i$ with the incorrect shared secret key should be notified and the user’s mistake should be sent to each user of the UG to discard the message generated by that user. Finally, if the user is reported by no less than t other users, the user is considered unqualified, otherwise it is qualified. The qualified users’ group $QU$ consists of these qualified users. After that, the secret shared key $s{k}_{ui}$ and secret key $s{k}_u$ of user $U_i$ are defined by Equations (4) and (5).

  $$s{k}_{ui}=\sum _{j\in QU}{s}_{ji}\left(modp\right),$$

  (4)

  $$s{k}_u=\sum _{j\in QU}{a}_{i0}\left(modp\right).$$

  (5)

• $Generatep{k}_{ui}andp{k}_u.$ Firstly, every user $U_i$ in the qualified users’ group $QU$ sends a variable value $A_{ik}(\mathrm{which}{A}_{ik}=g^{a_{ik}})$ to all other users $U_j$$(U_j\in QU)$ who verify the validity of $A_{ik}$ by Equation (6).

  $$g^{s_{ij}}=\prod _{k=0}^{t-1}\left(A_{ik}\right)j^k,1\le i\le n$$

  (6)
  If the result of Equation (4) is not equal, the inefficiency of $A_{ik}$ is monitored and t qualified users collaborate to rebuild the qualified $A_{ik}$ and resend the value again. Thus, we introduce two types of blockchains in our proposal. One is utilized to monitor the wrong behaviors during the signature generation, and the other is used for an incentive mechanism. Secondly, every qualified user $U_i$ sends their public shared key $p{k}_{ui}$ to all the other qualified users $U_j$ who verify the correctness of $p{k}_{ui}$ by Equation (7).

  $$p{k}_{ui}=\prod _{j\in QU}\prod _{k=0}^{t-1}\left(A_{jk}\right)i^k,1\le i\le n$$

  (7)
  If the result of Equation (7) is equal, the public shared key $p{k}_{ui}$ is qualified and accepted. Otherwise, the user $U_i$ must transmit the incorrect value $p{k}_{ui}$ but the correct value $p{k}_{ui}$ must be constructed by the formula in Equation (7). Moreover, this dishonest operation is recorded in blockchain. The right public shared key $p{k}_{ui}$ that is verified or regenerated by Equation (7) is regarded as the final public shared key $p{k}_{ui}$. Finally, the public key $p{k}_u$ is calculated by Equation (8).

  $${\mathit{pk}}_{\mathit{u}}={\mathit{g}}^{{\mathit{sk}}_{\mathit{u}}}$$

  (8)
  During this process, the identity message of each user who generates the qualified public shared key is monitored in the blockchain sequentially. The operation is utilized to achieve the incentive mechanism which urges each user to take part in the process and raises the efficiency of the signature generation.

Shared Signature Generation ($s{k}_{ui}$, $\alpha$, VID, m${}_b$, $N_b$)→($S_{ib}$): This is a shared signature generation algorithm for each user in the qualified users’ group. Firstly, suppose the file $\mathit{M}$ is divided into multiple outsourced file blocks. According to the multiblock signature technique, the outsourced file $\mathit{M}$ is split into $\mathit{s}$ data blocks; then, each block contains $\mathit{l}$ small data blocks, represented as Equation (9).

$$\begin{array}{c}M=M_{ab}{}_{1\le a\le l,1\le b\le s}\\ =(m_1{m}_2\cdots m_b\cdots m_s)\end{array}$$

(9)

$$=\left(\begin{array}{cccccc}{m}_{11}& m_{12}& \cdots & m_{1b}& \cdots & m_{1s}\\ m_{21}& m_{22}& \cdots & m_{2b}& \cdots & m_{2s}\\ ⋮& ⋮& ⋮& ⋮& ⋮& ⋮\\ m_{a1}& m_{a2}& \cdots & m_{ab}& \cdots & m_{as}\\ ⋮& ⋮& ⋮& ⋮& ⋮& ⋮\\ m_{l1}& m_{l2}& \cdots & m_{lb}& \cdots & m_{ls}\end{array}\right)$$

which $m_a=m_{ab1\le b\le s}=(m_{a1},m_{a2},\cdots ,m_{ab},\cdots ,m_{as})$

$m_b=m_{ab1\le a\le l}=(m_{1b},m_{2b},\cdots ,m_{ab},\cdots ,m_{lb})$

Secondly, the system calculates the extracted value of the DVG $\alpha$ with the designated verifier’s public key $p{k}_v$ and the secret key of user group $s{k}_u$ by Equation (10).

$$\alpha =H_2\left(p{k}_v^{s{k}_u}\right)$$

(10)

Finally, all users $U_{i,i\in [1,n]}$ run the algorithm to produce their own shared signatures $S_{ib}$ for every outsourced data block $m_{b,b\in [1,s]}$ with the identity of DVG $VID$, the secret shared key $s{k}_{ui}$, the number of file blocks $m_{b,b\in [1,s]}$, the identifier $N_{b,b\in [1,s]}$, and the extracted value of the DVG $\alpha$ by Equation (11).

$$S_{ib}=\left(H\right(\alpha \left|\right|VID\left|\right|N_b{)·g_1^{m_b})}^{s{k}_{ui}}$$

(11)

The shared signatures of t qualified users are utilized to generate the signature of all outsourced data blocks $m_{b,b\in [1,s]}$.

$SignatureSharingAggregation$ ($S_{ib}$, ${\lambda }_i$)→($S_b$): After obtaining t shared signatures, the aggregator $U_{agg}$ who originates from the UG generates the final signature of file block $m_{b,b\in [1,s]}$ by this algorithm. Firstly, the aggregator $U_{agg}$ audits the validity of the accepted multiple shared signatures by Equation (12).

$$e(S_{ib},g)=e\left(H\right(\alpha \left|\right|VID\left|\right|N_b)·g_1^{m_b},p{k}_{ui})$$

(12)

If the result of Equation (12) is equal, the aggregator $U_{agg}$ stores the signer’s identity in the blockchain in chronological order. Then, the aggregator $U_{agg}$ receives t correct shared signatures $S_{ib}$ to record the signers of these shared signatures in signature group $SG$ and aggregates the final signature $S_{b,b\in [1,s]}$ by Equation (13)

$$S_b=\prod _{i\in SG}{S}_{ib}{\lambda }_i=\left(H\right(\alpha \left|\right|VID\left|\right|N_b{)·g_1^{m_b})}^{s{k}_u}$$

(13)

where ${\lambda }_i={\prod }_{(j\in SG,j\ne i)}\frac{-j}{i-j}$ is a Lagrangian interpolation coefficient. Moreover, a user needs to verify the validity of the final signature $S_{b,b\in [1,s]}$ of file block $m_b$ by Equation (14).

$$e(S_b,g)=e\left(H\right(\alpha \left|\right|VID\left|\right|N_b)·g_1^{m_b},p{k}_u)$$

(14)

Every block of a data file may involve more than one signatures, because of all the members of a user group are able to choose t effective shared signatures of qualified users and aggregate the final signature, although only the earliest effective signature monitored in the blockchain is selected to handle this. Finally, it sends its data block to the CSP in the pattern of {$(m_b,N_b,S_b$${)}_{b\in [1,s]}$}.

$Challenge$ (c, $k_1, k_2$)→($chal$): The public auditing means that the designated verifier executes this algorithm to send a challenge question to the cloud storage provider and the CSP needs to answer the question. If the user $U_i$ wants to audit the integrity of outsourced file M, the designated verifier sets a challenge message $chal=\{c, k_1, k_2\}$ and sends it to the CSP, where $k_1,k_2\in Z_q^{*}$ are two random values and $c\in [1,s]$ is the number of challenged blocks.

$ProofGeneration$ ($\psi$, $r,chal$)→($pro$): Depending on the public data information stored in the system, the CSP executes this algorithm to set a file possession proof and sends it to the designated verifier. Firstly, when the cloud storage provider receives the $chal$, the CSP firstly computes $\iota ={\pi }_{k_1}\left(d\right),v_{\iota }=f_{k_2}\left(d\right),1\le d\le c$. After that, it aggregates all the outsourced file blocks’ tags $\psi ={\prod }_{\iota }\in T{S}_{\iota }^{v_{\iota }}\in G_1$. At last, the CSP selects a random value $r\to Z_q^{*}$, computes $R=e{(g_1,p{k}_u)}^r$, $\gamma$ = $H_3$$\left(R\right)$, $\mu =(r+\gamma ·{\sum }_{\iota \in T}{v}_{\iota }{m}_{\iota })\left(modp\right)$ (where

${\mu }^{\prime }=\gamma ·{\sum }_{\iota \in T}{v}_{\iota }{m}_{\iota }$) and sends the audit proof $pro=\{N_{b,b\in [1,s]},\mu ,\psi ,R\}$ to the designated verifier of DVG.

$\mathit{Designated}\mathit{Verifier}\mathit{Verification}({\mathit{sk}}_{\mathit{v}},{\mathit{pk}}_{\mathit{u}},\mathit{chal},\mathit{pro}$)→$(0,1)$: The designated verifier of the DVG executes this algorithm to verify the integrity of outsourced file $\mathit{M}$ with the audit proof. Firstly, the designated verifier calculates $\alpha =H_2\left(p{k}_u^{s{k}_v}\right)$, $\iota ={\pi }_{k_1}\left(d\right),v_{\iota }=f_{k_2}\left(d\right),1\le d\le c$ and verifies the audit proof $\mathit{pro}$ by Equation (15).

$$R·e({\psi }^{\gamma },g)=e\left(\right(\prod _{b\in [1,c]}H\left(\alpha \right|\left|VID\right||N_b{)}^{v_b}{)}^{\gamma }·g_1^{\mu },p{k}_u)$$

(15)

Finally, if the result is equal to that of Equation (13), the integrity of outsourced file block ${\mathit{m}}_{\mathit{b}}$ stored in the CSP is confirmed.

$IncentiveMechanism$$(coin, s{e}_b, N_b, p{k}_{ui})\to \left(U_{icoin}\right)$: The group users have same rights to generate key pairs and signatures because of the disappearance of the user group manager. However, group users may be unwilling to contribute to these operations, leading to inefficient calculations. To deal with this issue, we propose an incentive mechanism in this paper, by utilizing the characteristics of the blockchain, including decentralization, tamper-resistance, and traceability, to record some user information for fair rewards. The incentive mechanism is proposed to serve the user key-pair generation stage and signature generation stage based on the $(t,n)$ threshold signature. Its purpose is to, on the one hand, encourage all members of the user group to broadcast in response to a user $U_i$. Whether the response of this step is successful is related to whether the user $U_i$ can generate the correct key pair and become a qualified member of the user group. On the other hand, the users who encourage the generation of qualified key pairs, that is, the members of the qualified users’ group, will be composed of t qualified users who sign the data file block, and t qualified users who produce correct signatures from the signature group. In addition, in the signature generation scheme based on the $(t,n)$ threshold signature, the number of qualified user group members is at least t. Firstly, the outsourced file owner $U_i$ of data block $m_b$ defines the entire incentive reward $coin$ and the number of qualified signatories with contributions that the owner demands as t. Then, the server searches the blockchain to find the earliest valid contributors to give them rewards. The incentive mechanism is based on blockchain technology, which serves two main functions. The first is to record information. The incentive mechanism based on the blockchain accompanies the user in the whole process of signature generation, so the relevant information generated by the user key pair and the relevant information generated by the signature in this process is recorded. In addition, when the final signatures of all data files are generated before they are uploaded to the cloud, the blockchain-based incentive mechanism completes its first function. The second is the incentive mechanism to reward users for their contributions through the blockchain, so as to stimulate the user group to play an active role in the process of generating signatures.The information of valid contributors in the blockchain is set as $S{e}_b,N_b,p{k}_{ui}$${}_{,b\in [1,s]}$, where $S{e}_b$ is the sequence number, and $N_b$ is the file block number. Finally, in the incentive mechanism of our scheme, the rewards earned by effective contributors decrease over time. If the sequence number $S{e}_b$ is 1, the qualified signatories with contributions that generated the public shared key $p{k}_{ui}$ receive the incentive reward $U_{icoin}=$$\frac{coin}{{log}_{2}t}$. If the sequence number $S{e}_b$ is in the scope of $[2,3]$, the valid contributors receive the incentive reward $U_{icoin}=$$\frac{coin}{2{log}_{2}t}$. This is repeated until the sequence number $S{e}_b$ belongs to the scope of $[t/2,t]$ and the valid contributors receive the incentive reward $U_{icoin}=$$\frac{coin}{(t/2+1){log}_{2}t}$. Due to its quality, the blockchain is able to ensure that only the truly valid signers of shared signatures receive incentive fees.

5. Security Analysis

In this chapter, we deeply analyze the six security properties of our designed proposal, including correctness, robustness, homomorphic authentication, public auditing, unforgeability, and data privacy. These six security properties analyzed are detailed as follows.

5.1. Correctness

The key pairs and signatures generated correctly can pass the verification by an auditor. Thus, we analyze the security property of correctness from three aspects: users’ public shared keys, shared signatures of data blocks, and final signatures.

Theorem 1.

A correct user’s public shared key $p{k}_{ui}$ is able to pass the detection in Equation (7).

Proof. 

According to the secret shared value of user ${\mathit{U}}_{\mathit{i}}$${\mathit{s}}_{\mathit{ji}}={\mathit{f}}_{\mathit{j}}\left(\mathit{i}\right)={\sum }_{\mathit{k}=0}^{\mathit{t}-1}{\mathit{a}}_{\mathit{jk}}·{\mathit{i}}^{\mathit{k}}$ and the secret shared key of user ${\mathit{U}}_{\mathit{i}}$${\mathit{sk}}_{\mathit{ui}}={\prod }_{\mathit{j}\in \mathit{QU}}{\mathit{s}}_{\mathit{ji}}\left(\mathit{mod}\mathit{p}\right)$, we can derive the correctness of a user’s public shared key ${\mathit{pk}}_{\mathit{ui}}$ by Equation (16).

$$\begin{array}{c}p{k}_{ui}=g^{s{k}_{ui}}=g^{\left({\displaystyle \sum _{j\in QU}}{s}_{ji}\right)}={\displaystyle \prod _{j\in QU}}{g}^{s_{ji}}\\ ={\displaystyle \prod _{j\in QU}}{g}^{f_j\left(i\right)}={\displaystyle \prod _{j\in QU}}{g}^{\left({\displaystyle \sum _{k=0}^{t-1}}{a}_{jk}·i_k\right)}\\ ={\displaystyle \prod _{j\in QU}}{\displaystyle \prod _{k=0}^{t-1}}{\left(g^{a_{jk}}\right)}^{i^k}={\displaystyle \prod _{j\in QU}}{\displaystyle \prod _{k=0}^{t-1}}{\left(A_{jk}\right)}^{i^k}\end{array}$$

(16)

□

Theorem 2.

A correct shared signature $S_{ib}$ is able to pass the verification in Equation (12).

Proof. 

According to the public shared key of user ${\mathit{U}}_{\mathit{i}}$${\mathit{pk}}_{\mathit{ui}}={\mathit{g}}^{{\mathit{sk}}_{\mathit{ui}}}$ and the shared signature of block ${\mathit{m}}_{\mathit{b}}$ generated by user ${\mathit{U}}_{\mathit{i}}$${\mathit{S}}_{\mathit{ib}}=\left(\mathit{H}\right(\mathit{ff}\left|\right|\mathit{VID}\left|\right|{\mathit{N}}_{\mathit{b}}{)·{\mathit{g}}_1^{{\mathit{m}}_{\mathit{b}}})}^{\mathit{s}}{\mathit{k}}_{\mathit{ui}}$, we can derive the correctness of the shared signature generation algorithm by Equation (17).

$$\begin{array}{c}e(S_{ib},g)=e\left(\right(H\left(\alpha \right|\left|VID\right||N_b)·g_1^{m_b}{)}^s{k}_{ui},g)\\ =e\left(\right(H\left(\alpha \right|\left|VID\right||N_b)·g_1^{m_b}),g^{s{k}_{ui}})\\ =e\left(\right(H\left(\alpha \right|\left|VID\right||N_b)·g_1^{m_b}),p{k}^{ui})\end{array}$$

(17)

□

Theorem 3.

A correct final signature $S_b$ is able to pass the verification in Equation (14).

Proof. 

According to the final signature of block ${\mathit{m}}_{\mathit{b}}$${\mathit{S}}_{\mathit{b}}=\left(\mathit{H}\right(\mathit{ff}\left|\right|\mathit{VID}\left|\right|{\mathit{N}}_{\mathit{b}}{)·{\mathit{g}}_1^{{\mathit{m}}_{\mathit{b}}})}^{\mathit{s}}{\mathit{k}}_{\mathit{u}}$ and the public key of the UG ${\mathit{pk}}_{\mathit{u}}={\mathit{g}}^{{\mathit{sk}}_{\mathit{u}}}$, we can audit the validity of the final signature generation algorithm by Equation (18).

$$\begin{array}{c}e(S_b,g)=e\left(\right(H\left(\alpha \right|\left|VID\right||N_b)·g_1^{m_b}{)}^s{k}_u,g)\\ =e\left(\right(H\left(\alpha \right|\left|VID\right||N_b)·g_1^{m_b}),g^{s{k}_u})\\ =e\left(\right(H\left(\alpha \right|\left|VID\right||N_b)·g_1^{m_b}),p{k}^u)\end{array}$$

(18)

□

5.2. Robustness

Robustness means that our scheme can accept some passive members of the UG to participate in the generation of key pairs and signatures. During the process of selecting qualified users $QU$, we tolerate users who declined to generate their shared signatures to join $QU$. Different qualified users $QU$ have different public–secret key pairs. Moreover, the same user can become a member of a different qualified users’ group $QU$, so a different $QU$ is able to generate the same file block’s signature and the same $QU$ is able to generate different file block’s signatures. Therefore, the generated process of shared signatures is robust. The specific proof is shown below.

Theorem 4.

When less than t users of a user group is attacked by a malicious adversary, our scheme is still robust.

Proof. 

If a user is attacked by an adversary, the system can adopt two operations to maintain the security of our scheme: refuse to output results or broadcast incorrect information. A robust $(t,n)$ threshold signature can endure some half-honest signature members in the process of generating a signature. Assume that $X={\left\{U_i\right\}}_{i\in [1,t-1]}$ means the set of users attacked, and $Y={\left\{U_j\right\}}_{j\in [t,n]}$ means the set of honest users, where $n\ge 2t-1$. At first, during the generation of a user’s public shared key, when an attacked user $U_i\in X$ declines to produce their public shared key, the other honest users rebuild cooperatively the polynomial of the attacked user $U_i$ to compute a valid secret shared value $s_{ij}$. In addition, if the attacked user $U_i$ broadcasts an erroneous $A_{ik}$, $U_i$ cannot pass the verification according to Equation (6). Then, more t honest users $U_j\in Y$ calculate $A_{ik}(0\le k\le t-1)$ and valid public shared keys according to Equations (6) and (7). Next, in the process of generation of a user’s shared signature, if a dishonest user $U_i$ refuses to broadcast their signature sharing and the number of fully honest users is not less than t, other t honest users aggregate their shared signatures to produce cooperatively the final signature of the file block. In short, when less than t users are attacked by adversaries, the public shared keys of users can be produced validly in our scheme. Therefore, our provided $(t,n)$ threshold signature scheme is robust. □

5.3. Homomorphic Authentication

Homomorphic authentication is a basis of data auditing [15]; it has the attributes of unforgeability, blockless verification, and nonmalleability.

Theorem 5.

We adopt the homomorphic authentication technology to construct our scheme.

Proof. 

Besides the property of unforgeability, where only the members of the UG with qualified secret shared keys are able to produce valid shared signatures, we analyze in detail two other properties. At first, the security property of the blockless verification is analyzed. For instance, for two file blocks $m_1$ and $m_2$, given their file block identifiers $N_1$ and $N_2$, their signatures $S_1$ and $S_2$, the public key $p{k}_u$, and two random numbers $y_1$ and $y_2$, the designated verifier can audit the integrity of a linear combined block $m^{\prime }=y_1{m}_1+y_2{m}_2$ without knowing file blocks $m_1$ and $m_2$ by Equation (19).

$$\begin{array}{c}e({\displaystyle \prod _{b=1}^2}{S}_b^{y_b},g)=e({\displaystyle \prod _{b=1}^2}\left(H\right(\alpha \left|\right|VID\left|\right|N_b)·g_1^{m_b}{)}^{s{k}_u·y_b},g)\\ =e({\displaystyle \prod _{b=1}^2}\left(H\right(\alpha \left|\right|VID\left|\right|N_b)·g_1^{m_b}{)}^{y_b},g^{s{k}_u})\\ =e({\displaystyle \prod _{b=1}^2}\left(H\right(\alpha \left|\right|VID\left|\right|N_b)·g_1^{m^{\prime }}),p{k}_u)\end{array}$$

(19)

In addition, we certify that a malicious hacker without the private key $s{k}_u$ cannot produce the effective signature of the data file block. The reason for this nonmalleability is that hash function H is a one-way hash function. Given the equation $\theta =\left(H\right(\alpha \left|\right|VID\left|\right|N^{\prime }{\left)g^{m^{\prime }}\right)}^{s{k}_u}$ represents the signature of date block $m^{\prime }$, since

$S_1^{y_1}·S_2^{y_2}=({\prod }_{b=1}^2\left(H\right(\alpha \left|\right|VID\left|\right|N_b{{)}^{y_i}·g_1^{m^{\prime }})}^{s{k}_u}$, if $\theta$ can be verified, obviously

${\prod }_{b=1}^2\left(H\right(\alpha \left|\right|VID\left|\right|N_b{)}^{y_i}=\left(H\right(\alpha \left|\right|VID\left|\right|N^{\prime })$, which goes against the assumption that H is a one-way hash function. □

5.4. Public Auditing

Public auditing refers to the use of proof messages from cloud servers by designated verifiers of the DVG to audit the integrity of data stored in the cloud.

Theorem 6.

If the CSP stores the right outsourced file and replies to the designated verifier’s questions, the designated verifier can validly audit the integrity of the data.

Proof. 

According to the outsourced file stored $M=M_{ab,1\le a\le l,1\le b\le s}=m_{b,b\in [1,s]}$, the number of file block identifiers ${N_b}_{,b\in [1,s]}$, and the final signature of file block ${S_b}_{,b\in [1,s]}$, the CSP sets a file possession proof $Pro$. Via Theorem 5, $Pro$ is sent to the designated verifier from the cloud, and the integrity of the outsourced file is checked by Equation (15). When the proof information is calculated based on the relevant file data, the CSP can pass the audit.

$$\begin{array}{c}R·e({\psi }^{\gamma },g)=e{(g_1,p{k}_u)}^r·e({\left({\displaystyle \prod _{b\in [1,s]}}{S}_b^{v_b}\right)}^{\gamma },g)\\ =e{(g_1,p{k}_u)}^r·e\left(\right({\displaystyle \prod _{b\in [1,s]}}\left(H\right(\alpha \left|\right|VID\left|\right|N_b)·g_1^{m_b}{)}^{s{k}_u{v}_b}{)}^{\gamma },g)\\ =e(g_1^r,p{k}_u)·e\left(\right({\prod }_{b\in [1,s]}\left(H\right(\alpha \left|\right|VID\left|\right|N_b)·g_1^{m_b}{)}^{v_b}{)}^{\gamma },g^{s{k}_u})\\ =e(g_1^r,p{k}_u)·e\left(\right({\prod }_{b\in [1,s]}\left(H\right(\alpha \left|\right|VID\left|\right|N_b)·g_1^{m_b}{)}^{v_b}{)}^{\gamma {\mu }^{\prime }},p{k}^u)\\ =e({\prod }_{b\in [1,s]}H\left(\alpha \right|\left|VID\right||N_b{)}^{\gamma v_b}·g_1^{\gamma {\mu }^{\prime }}·g_1^{\gamma },p{k}^u)\\ =e({\prod }_{b\in [1,s]}\left(H\right(\alpha \left|\right|VID\left|\right|N_b{)}^{v_b}{)}^{\gamma }·g_1^{\mu },p{k}^u)\end{array}$$

(20)

□

5.5. Unforgeability

The basic element of the $(\mathit{t},\mathit{n})$ threshold signature is unforgeability, meaning only qualified users can generate correct signatures.

Theorem 7.

If no attacker knows the public key $p{k}_u$ and valid signature of file blocks $\{m_1,\cdots ,m_b\}$, we can generate correctness signatures for a fresh file block m that is different from $\{m_1,\cdots ,m_b\}$ with a non-negligible probability.

Proof. 

Define a malicious attacker $\mathit{A}$ that damages less than $\mathit{t}$ members of the UG and a challenger $\mathit{C}$ who responds to attacker $\mathit{A}$’s query by signing the oracle and hash function. Furthermore, we assume some different simulation games, $Gam{e}_0,Gam{e}_1,\cdots ,Gam{e}_5$, where ${\mathit{Forge}}_{\mathit{i}}$ means that the attacker wins in ${\mathit{Game}}_{\mathit{i}}$ during the game. During these games, we demonstrate that it is possible for the attacker $\mathit{A}$ to forge a qualified threshold signature by addressing the CDH assumption.

$Gam{e}_0:$ The attacker $\mathit{A}$ has access to a signed oracle ${\mathit{O}}_{\mathit{S}}$ and a random oracle ${\mathit{O}}_{\mathit{H}}$, the $t-1$ corrupted users in a team $\mathit{X}$ are defined in Theorem 4. The aim of the attacker $\mathit{A}$ is to fake a shared signature which can pass the audit. Given $Forg{e}_0$ represents the situation where a fake signature passes verification,

$$Suc{c}_A=Pr\left[Forg{e}_0\right]=ϵ$$

(21)

$Gam{e}_1:$ The corrupted members of the UG in team $\mathit{X}$ are $U_1,U_2,\cdots ,U_{t-1}$. Then, according to the probability to guess correctly defined in Theorem 4:

$$Pr\left[Forg{e}_1\right]=\frac{(t-1)!·(n-t-1)!}{n!}Pr\left[Forg{e}_0\right]<ϵ$$

(22)

$Gam{e}_2:$ Firstly, the challenger $\mathit{C}$ selects a random number $\mathit{a}\leftarrow {\mathit{Z}}_{\mathit{p}}$ and produces secret key ${\mathit{sk}}_{\mathit{u}}=\mathit{a}$ and public key ${\mathit{pk}}_{\mathit{u}}={\mathit{g}}^{\mathit{a}}$. After that, we execute the following steps for all members of the team $\mathit{X}$.

(1)

For each member of the team $\mathit{X}$, challenger $\mathit{C}$ randomly chooses $s{k}_{u1}^{\prime },\cdots ,s{k}_{ui}^{\prime }\in Z^p$ as secret shared keys for these members and defines public shared keys as ${\mathit{pk}}_{\mathit{ui}}={\mathit{g}}^{{\mathit{sk}}_{\mathit{ui}}^{\prime }}$ for these members. The public key is defined as ${\mathit{pk}}_{\mathit{u}}={\mathit{g}}^{{\mathit{sk}}_{\mathit{u}}^{\prime }}$.

(2)

For the fully honest members of the team $\mathit{Y}$, we calculate

$$s{k}_{ui}^{\prime }=\frac{1}{L(i,i)·(pk-{\sum }_{j-1}^{t-1}L(j,i)p{k}_{uj})}$$

(23)

where $\mathit{L}(\mathit{x},\mathit{y})$ is defined in [4] and $x,y\in [1,n]$.

(3)

The challenger chooses other $t-1$ random values $s{k}_{u1},\cdots ,s{k}_{u(t-1)}$ to define the public shared keys $p{k}_{ui}=g^{s{k}_{ui}}$ and secret shared key $s{k}_{ui}=x_i$ for these corrupted users.

(4)

For all fully honest members of the team Y, challenger C chooses $p{k}_{ut},p{k}_{u(t+1)},\cdots ,$$p{k}_{u(n-1)}\in G_1$ as their public shared keys and $p{k}_{ut}=p{k}_u-{\sum }_{i\in [1,n-1]}^{}s{k}_{ui}$ as the users’ ${\mathit{U}}_{\mathit{n}}$ public shared key.

(5)

At last, the challenger $\mathit{C}$ obtains the corresponding secret key ${\mathit{sk}}_{\mathit{u}}$ and public key ${\mathit{pk}}_{\mathit{u}}$ by integrating ${\mathit{sk}}_{\mathit{ui}}$ and ${\mathit{pk}}_{\mathit{ui}}$, respectively.

According to these steps, these numbers stay the same as the values in $Gam{e}_1$. The attacker $\mathit{A}$ cannot corrupt the $t-1$ users from this simulation game.

$$Pr\left[Forg{e}_2\right]=Pr\left[Forg{e}_1\right]<ϵ$$

(24)

$Gam{e}_3:$ Af first, attacker A can query $q_h$ times. During the hash query sent by attacker A, to insert the challenge ${\mathit{g}}^{\mathit{a}}$ into an oracle reply, challenger C randomly chooses a value $r\to Zp$ and calculates $H\left(\alpha \right|\left|VID\right||N_b)g_1^{m_b}={\left(g_1^{ab}\right)}^r$ when a new query $(N_b,m_b)$ is generated. After that, we save $(N_b,m_b,r,{\left(g_1^{ab}\right)}^r)$ in the hash list and send $H\left(\alpha \right|\left|VID\right||N_b)g^{m_b}$ as the reply back to the hash query. Since a random value r is chosen by $Z_p$, this simulation game is completely indistinguishable from $Gam{e}_3$.

$$Pr\left[Forg{e}_3\right]=Pr\left[Forg{e}_2\right]<ϵ$$

(25)

$Gam{e}_4:$ Challenger C proceeds if and only if $N_b,m_b$ has not been queried before and the output of $N_b,m_b$ passes the check. Since $\mathit{H}\left(\mathit{ff}\right|\left|\mathit{VID}\right||{\mathit{N}}_{\mathit{b}}){\mathit{g}}^{{\mathit{m}}_{\mathit{b}}}$ is indeterminate in $G1$, the probability of success in this simulation game is $1/p$.

$$|Pr\left[Forg{e}_4\right]-Pr\left[Forg{e}_3\right]|\le \frac{1}{p}$$

(26)

$Gam{e}_5:$ For all data information which has not been queried before, the challenger $\mathit{C}$ replies $\mathit{H}\left(\mathit{ff}\right|\left|\mathit{VID}\right||{\mathit{N}}_{\mathit{b}}){\mathit{g}}_1^{{\mathit{m}}_{\mathit{b}}}={\left({\mathit{g}}_1^{\mathit{ab}}\right)}^{\mathit{r}}$. Utilizing the equation $\left(\mathit{H}\right(\mathit{ff}\left|\right|\mathit{VID}\left|\right|{\mathit{N}}_{\mathit{b}}{\left){\mathit{g}}_1^{{\mathit{m}}_{\mathit{b}}}\right)}^{1/\mathit{r}}$ to pass the check, and defining ${\mathit{g}}_1^{\mathit{ab}}$ and ${\mathit{g}}_1^{\mathit{a}}$, $\mathit{C}$ can output ${\mathit{g}}_1^{\mathit{b}}$ with an attacker of $\mathit{Pr}\left[\mathit{Forge}5\right]$.

$$|Pr\left[Forg{e}_5\right]-Pr\left[Forg{e}_4\right]|\le \frac{q_h·q_s}{p}$$

(27)

According to Equations (21)–(25), we know that the probability that attacker $\mathit{A}$ is victorious in all games is ${ϵ}^{\prime }$. Therefore, when an attacker $\mathit{A}$ with a non-negligible probability characteristic produces forged messages, $Ad{v}_A^{CDH}={ϵ}^{\prime }$ has a non-negligible probability to address the $\mathit{CDH}$ problem, which conflicts with the $\mathit{CDH}$ assumption on ${\mathit{G}}_1$.

$${ϵ}^{\prime }\le \frac{(t-1)!·(n-t+1)!}{n!}·ϵ-\frac{1}{p}-\frac{q_h·q_s}{p}$$

(28)

Thus, an attacker $\mathit{A}$ cannot generate a forged signature in our scheme.

□

5.6. Data Privacy

In the public auditing process, our proposal is able to preserve file data messages safely for auditing.

Theorem 8.

The designated verifier cannot obtain the information of file blocks in the process of verifying data integrity.

Proof. 

In the data auditing process, the designated verifier seeds challenge message $chal=\{c,k_1,k_2\}$ to the CSP and receives the proof of data information $pro=\{N_{b,b\in [1,s]},\mu ,\psi ,R\}$. When a public designated verifier acquires the combined message ${\mu }^{\prime }={\sum }_{b\in [1,l]}{v}_b{m}_b$, the member of the DVG is able to get the privacy information of user’s data by obtaining many linear combinations of data block signatures and solving the resultant linear equations. This step’s difficult success lies in the use of blinding operation technology $\mu =r+\gamma {\mu }^{\prime }$, which blinds ${\mu }^{\prime }$ by randomly choosing a blinding value $r\to Z_p$. If the public designated verifier needs to solve bilinear equations, the verifier should know the random number r. Although the verifier can guess with a probability of $\{1/p\}$, the verifier may acquire the random value r from $R=e{(g_1,p{k}_u)}^r$ by deducing the random value of $e(g_1,p{k}_u)$. However, computing the random value r is as difficult as solving the discrete logarithm problem [8] in $G_1$, which is computationally impossible. Thus, the attacker cannot get the information of file block $m_b$ by solving a set of linear equations. □

6. Performance Analysis

In this section, we display the feasibility of our proposal with a theoretical analysis of cloud computation, communication, and storage costs, and then evaluate the experimental results. In order to better indicate the characteristics of our scheme, we compared our proposal with the scheme in [4] and that in [17]. In addition, we show the functions of our proposal compared with the other two schemes [4,17] in

Table 2. Functionality comparison.

	Our Scheme	[4]	[17]
Identity-based	Yes	No	Yes
Designated verifier	Yes	No	Yes
$(\mathit{t},\mathit{n})$ threshold	Yes	Yes	No
Multiblock signature	Yes	No	No
Blinding technology	Yes	Yes	No
Homomorphic authenticator	Yes	Yes	Yes
Traceability	Yes	Yes	No
Incentive mechanism	Yes	Yes	No

. The purpose of the table is to compare the relevant technologies used in this paper with those of the other two papers, and to show the improvement of our scheme from different aspects and the advantages of the whole data integrity audit scheme from that side.

6.1. Theoretical Analysis

Let $T_p$ represent the computational overhead of a pairing operation on the groups $G_1$ and $G_2$, and let $T_{mul}$ and $T_{exp}$, respectively, represent the computational overhead of a multiplication operation and an exponentiation operation. In addition, we ignore the computation cost of addition operations and the operation of hashing. In our proposed scheme, the outsourced file M is split into s data blocks, every block containing l small data blocks. This means that the number of all data blocks in the other two schemes is $l·s$. The number of challenged blocks in each challenge step is c.

$ComputationalCostAnalysis:$ During the final signature generation, firstly, each qualified users $U_{i,i\in QU}$ can generate shared signature $S_{ib}$ for all data blocks $m_{b,b\in [1,s]}$. Then, t shared signatures passing the verification are aggregated to produce the final signature. Therefore, the computational cost of aggregating the final signature of all file blocks $SignGen$ is $st(2T_{exp}+(3t-1)T_{mul})$. Due to the use of PRP and PRF in our scheme, the computational cost of the algorithmic challenge is negligible. In the process of proof generation, the designated verifier produces a challenge information $chal$ after receiving the designated audit work from the member of the user group. The CSP generates a verification proof $pro=\{N_{b,b\in [1,s]},\mu ,\psi ,R\}$ based on the received challenge message $chal$, thus the computational costs of $\mu$,$\psi$ and R are $(c+1)T_{mul}$, $c{T}_{exp}+c{T}_{mul}$ and $T_{ecp}+T_p$, respectively. Meanwhile, the total computational cost of generating proof $ProGen$ is $(c+1)T_{exp}+(2c+1)T_{mul}+T_p$. During the designated verifier verification, the total computational cost of verifying proof $ProVer$ is $(c+3)T_{exp}+(c+2)T_{mul}+2T_p$.

Table 3. Computational cost.

	SignGen	ProGen	ProVer
Our Scheme	$\mathit{st}(2{\mathit{T}}_{\mathit{exp}}+(3\mathit{t}-1){\mathit{T}}_{\mathit{mul}})$	$(\mathit{c}+1){\mathit{T}}_{\mathit{exp}}+(2\mathit{c}+1){\mathit{T}}_{\mathit{mul}}+{\mathit{T}}_{\mathit{p}}$	$(\mathit{c}+3){\mathit{T}}_{\mathit{exp}}+(\mathit{c}+2){\mathit{T}}_{\mathit{mul}}+2{\mathit{T}}_{\mathit{p}}$
[4]	$\mathit{lst}(2{\mathit{T}}_{\mathit{exp}}+(3\mathit{t}-1){\mathit{T}}_{\mathit{mul}})$	$(\mathit{lc}+1){\mathit{T}}_{\mathit{exp}}+(2\mathit{lc}+1){\mathit{T}}_{\mathit{mul}}+{\mathit{T}}_{\mathit{p}}$	$(\mathit{lc}+3){\mathit{T}}_{\mathit{exp}}+(\mathit{lc}+2){\mathit{T}}_{\mathit{mul}}+2{\mathit{T}}_{\mathit{p}}$
[17]	$\mathit{ls}(2{\mathit{T}}_{\mathit{exp}}+2{\mathit{T}}_{\mathit{mul}})$	$(\mathit{lc}+1){\mathit{T}}_{\mathit{exp}}+(\mathit{lc}-1){\mathit{T}}_{\mathit{mul}})$	$3{\mathit{lcT}}_{\mathit{exp}}+2{\mathit{lcT}}_{\mathit{mul}}+3{\mathit{T}}_{\mathit{p}}$

presents the computational cost of our scheme and that of the other two schemes.

$\mathit{Communicational}\mathit{Cost}\mathit{Analysis}:$ In most PDP-based proposals, the communication cost is mainly from the process of storing data from the UG to the CSP and the challenge and proof messages transmitted between the CSP and the DVG. We analyze the communication cost of our proposal in three steps: UG-to-CSP phase, DVG-to-CSP phase, and CSP-to-DVG phase. When the data are uploaded by the UG to the CSP, the UG sends s data blocks to the CSP with corresponding tags including the number of signed block identifier $N_b$ and data block signatures $S_b$. It is important to know that in our proposal, each data block and the number of signed block identifiers are of size $Z_q$, each signed block signature is of size $G1$. Thus, the total communication cost in the UG-to-CSP phase is $(ls+s)|Z_q|+s|G_1|$. In addition, the communication cost of our proposal in the UG-to-CSP phase is less than that of the other two proposals. Since we aggregate the signature of every s signed block when generating signatures, the number of final signatures are less than the number of all data blocks $l·s$. During the challenge phase from the DVG to the CSP, the total communication cost in the DVG-to-CSP phase is $3|Z_q|$. During the proof generation by the CSP to the DCG, when the CSP receives the data information from a challenge, the cloud produces the data integrity proof and sends the proof $pro$ back to the designated verifier. Therefore, the total communication cost in the CSP-to-DVG phase is $(lc+c)|Z_q|+c|G_1|+c|G_2|$.

Table 4. Communication cost.

	UG to CSP	DVG to CSP	CSP to DVG
Our Scheme	$(\mathit{ls}+\mathit{s})|{\mathit{Z}}_{\mathit{q}}|+\mathit{s}|{\mathit{G}}_1|$	$3|{\mathit{Z}}_{\mathit{q}}|$	$(\mathit{lc}+\mathit{c})|{\mathit{Z}}_{\mathit{q}}|+\mathit{c}|{\mathit{G}}_1|+\mathit{c}|{\mathit{G}}_2|$
[4]	$2\mathit{ls}|{\mathit{Z}}_{\mathit{q}}|+\mathit{ls}|{\mathit{G}}_1|$	$3|{\mathit{Z}}_{\mathit{q}}|$	$2\mathit{lc}|{\mathit{Z}}_{\mathit{q}}|+\mathit{lc}|{\mathit{G}}_1|+\mathit{lc}|{\mathit{G}}_2|$
[17]	$2\mathit{ls}|{\mathit{Z}}_{\mathit{q}}|+\mathit{ls}|{\mathit{G}}_1|$	$3|{\mathit{Z}}_{\mathit{q}}|$	$2\mathit{lc}|{\mathit{Z}}_{\mathit{q}}|+\mathit{lc}|{\mathit{G}}_1|$

presents the communication cost for our scheme and the other two schemes.

$StorageCostAnalysis:$ We are mainly concerned with the storage cost of the UG, CSP and DVG. From the UG’s perspective, after data are stored to the CSP, the UG destroys all other data locally except for each user’s own private key $s{k}_{ui}$, user group’s secret key $s{k}_u$, and the extracted value of the DVG $\alpha$. Thus, the storage cost of the UG is $3n|Z_q|$. The CSP just requires saving the outsourced file data blocks, corresponding identifiers the signed blocks, and their signatures. In our proposed signature, each l small block of data has a tag. Thus, the total storage cost of the CSP is $(ls+s)|Z_q|+s|G_1|$. The DVG needs to store its own private key $s{k}_v$ and user group’s public key $p{k}_u$, so the storage cost is $2|Z_q|$.

Table 5. Storage cost.

	UG	CSP	Title DVG
Our Scheme	$3\mathit{n}|{\mathit{Z}}_{\mathit{q}}|$	$(\mathit{ls}+\mathit{s})|{\mathit{Z}}_{\mathit{q}}|+\mathit{s}|{\mathit{G}}_1|$	$2|{\mathit{Z}}_{\mathit{q}}|$
[4]	$2\mathit{n}|{\mathit{Z}}_{\mathit{q}}|$	$2\mathit{ls}|{\mathit{Z}}_{\mathit{q}}|+\mathit{ls}|{\mathit{G}}_1|$	$|{\mathit{Z}}_{\mathit{q}}|$
[17]	$|{\mathit{Z}}_{\mathit{q}}|$	$2\mathit{ls}|{\mathit{Z}}_{\mathit{q}}|+\mathit{ls}|{\mathit{G}}_1|$	$|{\mathit{Z}}_{\mathit{q}}|$

presents the storage cost for our scheme and the other two schemes.

6.2. Experimental Results

In order to better evaluate our proposed scheme, we implemented it by utilizing the 512-bit elliptic curve from the Pairing-Based Cryptography (PBC) Library [32] and the GNU Multiple Precision Arithmetic (GMP) Library [33]. All of the experiments were conducted on a UTM virtual machine with a configuration of 8G of RAM, two CPUs, a 64G disk, and the Ubuntu operating system. We used a MacBook Pro Laptop as the host computer with the macOS Big Sur 11.4 operation system, a Core Apple M1 and 16G of RAM.

In our experiments, we compared the computational cost of our scheme with the schemes in [4,17], including the final signature generation $\mathit{SignGen}$, proof generation $\mathit{ProGen}$, and designated verifier verification $\mathit{ProVer}$. We set an outsourced file with a size of 2 MB, which was split into 100 data blocks (according to the multiblock signature technique, we first divided the data file into 10 data blocks, each block containing 10 small data blocks). To ensure the diversity of the experiments, the count of data blocks was varied from 100 to 400, 900, 1600, and 2500. For the number of challenged data blocks $\mathit{c}$ of a data file, we set their number to 10, 40, 90, 160, and 250, respectively. Moreover, we defined the number of members of user group $\mathit{n}$ as 10, of which the number of qualified users $\mathit{t}$ was 5 ($\mathit{n}/2$). All experiments were conducted 10 times to obtain more precise results.

$\mathit{Computational}\mathit{cost}\mathit{for}\mathit{SignGen}:$ In the first experiment, we compared the performance of the $\mathit{SignGen}$ of the three proposals, and the experimental results are shown in Figure 3. The horizontal axis of Figure 3 displays the number of data blocks utilized to generate the final signatures, and the vertical axis displays the computational time taken. As can be seen from Figure 3, when the number of data blocks increased, the computational time cost also increased linearly. The computational cost of the final signature generation $\mathit{SignGen}$ in our proposed scheme was much higher than that of the scheme in [4], but lower than that of the scheme in [17]. The main reasons were: On the one hand, qualified users needed to sign all data blocks in scheme [4], but just signed partial data blocks in our scheme. On the other hand, each data block was signed by $\mathit{t}$ qualified users in our scheme, but the data blocks were just signed by one user in scheme [17]. However, our scheme had the advantage of sharing data among multiple users and eliminating managers compared to scheme [17].

$\mathit{Computational}\mathit{cost}\mathit{for}\mathit{ProGen}:$ In the second experiment, we compared the performance of the $ProGen$ of the three proposals, and the experimental results are shown in Figure 4. The horizontal axis of Figure 4 represents the number of challenge blocks utilized to generate the proof message, and the vertical axis displays the computation time taken. As we can see, the computational cost of the proof generation $ProGen$ in our proposed scheme was less than that in the scheme in [4] and the scheme in [17], because the number of challenged data blocks c in our proposed scheme was much smaller than that of the other two schemes.

$ComputationalcostforProVer:$ In the last experiment, we compared the performance of the $ProVer$ of the three proposals, and the experimental results are presented in Figure 5. The horizontal axis of Figure 5 displays the number of challenged blocks utilized to verify the proof by a designated verifier, and the vertical axis displays the computation time taken. We can see that the computational cost increased linearly as the number of data blocks increased. Since the number of challenged data blocks c in our proposal was much smaller than in [4,17], the computational cost of the designated verifier verification $ProVer$ was less than in the two other schemes.

Summarily, from the comparison of the experimental results, our designed scheme was more efficient, specifically in the generation of proofs and the auditing of designated validators. For the generation of the final signature, although the computational efficiency of our scheme was not the best, it was still competitive due to the $(\mathit{t},\mathit{n})$ threshold signature, incentive mechanism, and multiblock signature technique.

7. Conclusions

In this study, we designed an incentivized public auditing scheme with an identity-based designated verifier in the cloud. In our propose scheme, each user of the user group was able to generate their own key pair and file block signatures by utilizing $(\mathit{t},\mathit{n})$ threshold technology. To ensure all users could take part in the user key generation and the signature generation fairly, equally, and decentralized, during the process of auditing, only the identity-based designated verifier could verify the integrity of the user’s data stored in the CSP to eliminate the half-honest auditors in traditional data-integrity-audit protocols. Additionally, the multiblock signature technology reduced the computational overhead in the data block signature phase and the data audit process. The security analysis and the performance analysis demonstrated that our designed scheme realized the desirable correctness, robustness, security, efficiency, and unforgeability.