Identity-based remote data checking with a designated verifier

Traditional remote data possession auditing mechanisms are usually divided into two types: private auditing and public auditing. Informally, private auditing only allows the original data owner to check the integrity of its outsourced data, whereas anyone is allowed to perform the checking task in public auditing. However, in many practical applications, the data owner expects some designated verifier (instead of others) to audit its data file, which cannot be covered by the existing private or public auditing protocols. Thus, in a recent work, Yan et al. proposed a new auditing technique with a designated verifier [IEEE Systems Journal, 12(4): 1788-1797, 2020]. Nevertheless, we note that this protocol suffers from complicated management of certificates and hence heavily relies on public key infrastructure. To overcome this shortcoming, in this paper, we propose an identity-based auditing protocol with a designated verifier, which not only avoids the introduction of certificates, but also has the desired property of only allowing specific verifier to audit. Its security is based on the classical computational Diffie-Hellman and Weil Diffie-Hellman assumptions. Finally, performance analysis shows that our proposed protocol is very efficient and suitable for some real-life applications.


Introduction
In recent years, cloud storage has become an attractive technique for users or data owners (DOs) to store their data since it may have much lower prices than the cost to maintain them on personal devices. When enjoying the services provided by cloud companies, the DOs can freely access and conveniently share these outsourced data on different devices and locations. However, they also completely lose the control of its data after uploading them to the cloud service provider (CSP). Meanwhile, for kinds of internal or external reasons, it is extremely possible to lose user's data for the CSP [1]. For example, the CSP may deliberately delete user's rarely used data to save its own space and thus attract more clients to gain more economic benefits. In addition, the cloud companies may also be attacked by hackers and hence "passively" lose user's data [2]. Under this situation, the DOs naturally worry about the integrity of their outsourced data and urgently hope that there exists a mechanism to help them to audit or check data's integrity. If it is broken, then they should obtain compensations. As a result, remote data possession checking (RDPC) mechanisms, like provable data possession (PDP) or proof of retrievability (PoR) were developed and broadly studied in the last decades [3,4].
According to the manners of auditing, RDPC mechanisms are divided into two types: private auditing (see [5]) and public auditing (see [6]). In private auditing, the auditor is just the DO itself. But in public auditing, anyone is allowed to perform the task of auditing. A popular way is to outsource the auditing task to some third-party auditor (TPA), who may have more professional knowledge on auditing and more computing power. Therefore, the public auditing is very popular in practical applications.
However, in some situations, the DO hopes or needs to limit the verifier's identity, and just allows a designated auditor to check its data's integrity. For example, a financial staff in a company outsourced some sensitive data, (2022) 11:7 Page 2 of 14 such as employees' salaries, to some CSP. Then the chief financial officer is just the one that is allowed to check the integrity of these data. Another example is that some TPA company gives its clients a lower discount if the DO only chooses this TPA company (instead of others) as the auditor of its stored data. Therefore, in these practical scenarios, how to design RDPC mechanisms with a designated verifier is an interesting but challenging problem. In [7], Yan et al. recently designed an efficient designated-verifier PDP (DV-PDP, for short) protocol, where the DO specifies a designated verifier to audit the integrity of its data. Meanwhile, they also analyzed its security in the random oracle model. However, it is well known that most of the existing public (DV-)PDP protocols are based on the management of certificates and heavily relies on public key infrastructure (PKI) technique [8]. The reason lies in that other entities in the protocol need to securely obtain and use the public keys of some participants, but how to fix the relationship between the received public key and its true identity is hard to handle. In other words, the genuineness of user's public key is hard to guarantee. The traditional method is issuing certificates for these users by a trusted certificate authority (CA) center. However, the complex management procedures on certificates, including generation, storing, delivery, updating, and revocation etc., additionally increase communication/computational costs, which are time-consuming and expensive, and thus greatly reduce the efficiencies of the designed PDP protocols. In addition, PKI's security cannot be completely guaranteed, especially when CA center is controlled by some malicious hacker. For instance, after discovering more than 500 fake certificates, web browser vendors were forced to blacklist all certificates issued by DigiNotar, a Dutch CA, in 2011 [9].
Motivation. We note that the identity-based (IB) cryptography does not suffer this problem [10]. More specifically, in identity-based primitives, user's public key is set as its name, email address, or identity-card number and so on, which does not need the certificates to authenticate its validity. Then a trusted key generation center (KGC) generates secret keys for different users corresponding to these identities. When all users have their secret keys issued by the same KGC, individual public keys become obsolete, which removes the need for explicit certification and all necessary costs. These features make the identity-based paradigm particularly appealing for use in conjunction with PDP protocols. This is also the reason why many proposed PDP protocols were twisted into IB-PDP ones [11,12]. Hence, it becomes an interesting problem to introduce the identity-based technique to IB-PDP protocol.
Our Contributions. In this paper, we consider the new notion of IB-PDP protocol with a designated verifier (IB-DV-PDP, for short), which can be seen as an improvement on DV-PDP proposed by Yan et al. in [8]. The main contributions of this paper can be summarized as follows.
1) For the first time, we propose the notion of IB-DV-PDP protocol, which provides the integrity checking of user's stored data under the constraint of a designated verifier. In our proposed protocol, anyone knows the cloud user's identity but only the designated verifier is allowed to perform the auditing task on behalf of the data owner, which may find special applications in practical scenarios. 2) Second, we define the security model of IB-DV-PDP protocol, which not only satisfies the security definition of previous IB-PDP protocol, but also describes the security against un-designated verifier. More precisely, we first consider the security against malicious CSP, which is the essential security for PDP protocol. Then in order to guarantee the DV's interests, we discuss the security against any unauthorized verifier. 3) Then, we propose a concrete construction of IB-DV-PDP protocol and prove its security within our model based on the computational Diffie-Hellman (CDH) and Weil Diffie-Hellman (WDH) assumptions. Meanwhile, we emphasize that this security relies on the classical random oracle model. 4) Finally, we also analyze the performances of our proposed protocol, including the communication overheads, computational/storage costs (theoretical analysis), and experimental results, which shows that our protocol is very efficient and suitable for practical applications.
Related Works. In 2007, Juels et al. first proposed the notion of PoR to model the security of outsourced data, where the error-correcting code was combined with the spot-checking of data to verify the integrity [13]. However, this scheme does not support public checking and only allows limited number of checking. At the same time, Ateniese et al. presented a similar technique named PDP, which is based on the RSA-homomorphic authenticators [14]. It allows public auditing and unlimited number of verifications. Later, Dodis, Vadhan and Wichs constructed PoR schemes via hardness amplification [15]. Note that the notion PoR is obviously stronger than PDP. Therefore, constructing a secure PDP protocol is easier than instantiating a PoR scheme. In 2017, Zhang et al. presented a general framework to design secure PDP protocols using homomorphic encryption schemes [2].
In 2016, Chen et al. first revealed an intrinsic relationship between network coding (see [16][17][18]) and secure cloud storage protocol, although both of them seem to be very different in their nature and were studied independently [19]. But the reverse direction does not hold in general unless imposing additional constraints. In recent work [20], Chang et al. defined a new notion of admissible PoR and proved that it is also possible to design secure network coding from admissible PoR protocols.
Consider that most of the previous PDP or PoR protocols heavily reply on PKI technique and must deal with complicated management of public key certificates. As a result, many identity-based PDP or PoR protocols were also proposed in past years,which borrow the identitybased idea in public key cryptography [10].More concisely, Wang et al. designed IB-PDP protocol in public clouds [21], in which they did not consider the problem of data's privacy preserving. Then, in 2017, Yu et al. constructed a secure IB-PDP protocol with perfect data privacy preserving to improve Wang et al. 's result [9]. Moreover, Xue et al. designed identity-based public auditing protocol against malicious auditors via the new technique of blockchain [12].
In order to decrease the system complexity, later, Li et al. also proposed a new identity-based data storage protocol, which uses homomorphic verifiable tag to achieve it [8]. In addition, in multi-copy-multi-cloud case, they also considered the efficient construction of IB-PDP protocol [22]. Recently, Chang et al. revisited this protocol and proposed some improvements on its performances [23].
In addition, Zhang et al. constructed an IB-PDP protocol, which is secure against key-exposure attack and based on Lattices [24]. Later, Mary and Rhymend proposed a stronger key-exposure model and gave some suggestions on how to construct this kind of IB-PDP protocol [25].
Note that the previous IB-PDP protocols did not consider the designated-verifier case. Hence, our proposed IB-DV-PDP protocol is the first one and will find applications in practical scenarios.
Organizations. The organizations of this paper are as follows. In "Preliminaries" section, we introduce some basic notations and notions. In "Our proposed construction and its security" section, the proposed protocol and its security analysis are given. In "Performances analysis" section, we analyze the performances and compare them with three other related PDP protocols. Finally, conclusions are presented in "Conclusions" section.

Basic notations
Now, we first present the basic notations used in this paper. More precisely, we use λ or 1 λ to denote the security parameter. PPT is the abbreviation of "Probabilistic Polynomial Time". For a natural number n, the symbol [ n] means the set of {1, 2, · · · , n}. For an algorithm A, the symbol "y ← A(x 1 , x 2 , · · · )" denotes that it takes x 1 , x 2 , · · · as inputs, and will output y. For a group G, |G| denotes the bit length of each element in it. A function f (λ) is negligible if, for any c > 0, there exists a λ 0 ∈ Z such that for any λ > λ 0 , it always holds that f (λ) < λ −c . Other symbols and their corresponding definitions are listed in Table 1.

Blinear map
Consider two cyclic groups G 1 , G 2 with the same prime order q. A map e : G 1 × G 1 → G 2 is called a bilinear map if the following conditions hold.
• Non-Degeneracy. For any generators g 1 , g 2 of G 1 , it holds that e(g 1 ,

CDH assumption
Define G 1 as a cyclic group with prime order q and generator g. Randomly choose a, b from Z q and compute The CDH assumption means that, given the tuple (g, g a , g b ), any PPT algorithm cannot compute and output the element g ab ∈ G 1 .

Weil Diffie-Hellman Assumption
Here, we recall the Weil Diffie-Hellman (WDH) assumption in [26]. Let e : G 1 × G 1 → G 2 be a bilinear map and g be a generator of G 1 . Randomly choose a, b, c from Z q and compute g a , g b , g c . The WDH assumption refers to that, given the tuple (g, g a , g b , g c ), there is no efficient algorithm to compute e(g, g) abc ∈ G 2 .

System model
In this subsection, we formally introduce the system model of IB-DV-PDP protocol. A graphical description can be found in Fig. 1. In particular, the whole system includes four entities: KGC, DO, DV, and CSP.
• KGC: Given the identity of DO or DV, this entity will issue secret key for it. • DO: This entity is just the data owner, who intends to outsource its original data file to some CSP. • DV: This is an entity which is designated by DO and will check the integrity of DO's stored file. • CSP: This entity has great storage spaces and provides storing services for lots of DOs.
Then, an IB-DV-PDP protocol consists of the following seven PPT algorithms.
• (params, msk) ← Setup(1 λ ). This algorithm initializes the system and generates the public system parameter params as well as the master secret key msk. • sk ID ← Extract(msk, ID). This algorithm generates secret keys for users (including the DV) with different identities ID. Now, the DO (resp. DV) can obtain its secret key sk O (resp. sk V ) by inputting its identity ID O (resp. ID V ) into this algorithm.
This is a trapdoor-generation algorithm, which takes the pair (sk O , ID V ) or (sk V , ID O ) as input, and computes a common private trapdoor trd between the DO and DV. • T ← TagGen(sk O , F). This algorithm is run by DO to generate an authenticated file T for the original data file F. Then T is transmitted to a CSP for storing. • chal ← Challenge. This is an algorithm run by the DV (in the auditing phase) to generate a challenge message chal, which will be sent to the CSP. • ← ProofGen(chal, T). When receiving the challenge message chal from the DV, the CSP computes a proof based on the stored T. • b ← Verify(trd, chal, ). This is the final checking algorithm of the DV, which will output a bit b based on the challenge message chal and the returned proof . If b = 1, then the DO's stored data file is intact. Otherwise, its integrity is broken.
When combining the entities with the above algorithms, the system will work as follows. The KGC first runs Setup to obtain params and msk, and broadcasts params to other entities. Given the identity ID, the KGC runs sk ID ← Extract(msk, ID) and returns sk ID to the entity with ID. After receiving the secret key sk O and DV's identity ID V , the DO computes the trapdoor trd, which can also be computed by the DV, by running TrapdoorGen. Then the DO continues to generate the authenticated file T for the original data file F by performing TagGen(sk O , F), and transmits T to CSP for storing. In the auditing phase, the DV runs Challenge to get chal and sends it to CSP, who will compute based on chal and the stored T, and then returns it to the DV. Finally, the DV checks the validity of the returned by running Verify.

Security model
In this subsection, we define the security model of an IB-DV-PDP protocol. Before describing its definition, we would like to give some underlying intuition. Concretely, here, we need to consider two kinds of attacks. One is to model the misbehavior of malicious CSP. That is, if some stored data blocks are lost by CSP, then the designated verifier can detect it with extremely high probability. Another one is to model the security of DV, which also means that checking whether an un-designated verifier is able to perform the task of auditing or not. For a secure IB-DV-PDP protocol, it should satisfy that any un-designated verifier cannot obtain the corresponding trapdoor and thus cannot perform the task of auditing. Now, we formally give the definition of the former one, which is modeled by the following security game played between a challenger CH I and an adversary CSP.
• Initialization. The challenger first runs Setup(1 λ ) to get the public system parameter params and the master secret key msk. Give params to CSP. • Queries. The adversary is allowed to adaptively make the following queries.
-Secret-Key-Extract. CSP submits an identity ID to CH I , who will run sk ID ← Extract(msk, ID) and return sk ID to it. -Authenticated-File-Query. The adversary CSP submits an identity ID and a data file F to CH I , who runs and returns it to CSP. -Auditing-Query. This kind of query is based on the queried T in the previous step. More precisely, the challenger first runs chal ← Challenge and gives chal to CSP, who computes and returns a proof by running ProofGen(chal, T). When receiving , CH I obtains the trapdoor trd by running the algorithm TrapdoorGen(sk O , ID V ), and continues to run b ← Verify(trd, chal, ).
Finally, the bit b is transmitted to CSP.
• Final Phase. In this phase, the challenger CH I submits a challenge message chal * to CSP in order to check the integrity of some data file F queried in Authenticated-File-Query, who finally returns a proof * .
If 1 ← Verify(trd, chal * , * ), and the following conditions hold, 1) The identities ID O and ID V are not queried to the oracle Secret-Key-Extract, and 2) The returned proof * does not equal to the correct one , which would be honestly computed in ProofGen(chal * , T), then we call the IB-DV-PDP protocol is secure against any PPT malicious CSP. Next, we consider the security on the trapdoor of the DV. In order to clearly introduce the security model on trapdoor, we would like to give some underlying intuition. More concretely, for an adversary, it wants to find the correct trapdoor after seeing the transmissions between the entities, including the initialization, queries and so on. Here, we still introduce the following security game played by a challenger CH II and an adversary A.
• These phases "Initialization" and "Queries" are the same as the ones appeared in the above game except that CH I and CSP are replaced by CH II and A, respectively. • Final Phase. In final, the adversary outputs a trapdoor trd * . Naturally, the restriction is that A is not allowed to query ID O and ID V to Secret-Key-Extract oracle.
If for any PPT adversary A, the probability that its output trd * equals to the trapdoor trd of the DV is negligible, then we call the IB-DV-PDP protocol is secure for the DV. In other words, this security describes that any undesignated entity is "hard" to obtain the trapdoor and hence is not able to perform the task of auditing.

Our proposed construction and its security
Now, we formally introduce the construction of our proposed IB-DV-PDP protocol as follows.
• (params, msk) ← Setup(1 λ ): This is an algorithm that generates the system parameters params and KGC's master secret key msk when given the security parameter 1 λ . Concretely, it chooses two cyclic groups G 1 , G 2 with the same prime order q (|q| ≥ λ), and e a bilinear map from G 1 × G 1 to G 2 . Assume that g is a generator of G 1 , and H 1 , H 2 are two hash functions from {0, 1} * to G 1 . Moreover, define φ : Z * q × {1, 2, · · · , n} → Z * q , π : Z * q × {1, 2, · · · , n} → {1, 2, · · · , n} as pseudorandom function and pseudorandom permutation, respectively. Then randomly choose x from Z * q and compute P 0 = g x . Finally, set and msk = x. • sk ID ← Extract(msk, ID) : This is a secret-key-generation algorithm for a user with identity ID. In particular, for the inputs of KGC's master secret key msk and user's identity ID, it computes sk ID = H 1 (ID) x and outputs it as the generated secret key (for ID ). In fact, by running this algorithm, the DO with identity ID O and the DV with ID V can obtain their secret keys sk O and sk V , respectively.
, then this algorithm computes the trapdoor trd as follows.
Similarly, if the input is (sk V , ID O ), then this algorithm computes the trapdoor trd as follows.

Now, define
and output it, which will be transmitted to CSP for storing. • chal ← Challenge: This is the challenge-messagegeneration algorithm and run by the DV. In particular, in order to check the integrity of user's data, the designated verifier randomly chooses from [ n], which denotes the number of challenged blocks, and k 1 , k 2 from Z * q . Output the challenge message chal = ( , k 1 , k 2 ), which will be sent to CSP. • ← ProofGen(chal, T) : This algorithm will generate the returned proof and hence run by the CSP. Specifically, when receiving the challenge message chal from the verifier, it first computes Finally, return to the DV. • 1/0 ← Verify(trd, chal, ) : After receiving the returned proof from CSP, the DV first checks if T Fid is a valid signature on the message (u 1 ||u 2 || · · · ||u s ||R||Fid). If it isn't, refuse this proof and output 0. Otherwise, compute a i , c i from k 1 , k 2 as in (2). Then check if in which M j is the j th component of M. If it is, output 1. Otherwise, output 0. The correctness of (3) can be verified as follows.

Brief review of yan et al.'s dV-PDP protocol
In order to clearly express our improvement on Yan et al. 's DV-PDP protocol, here, we briefly review their protocol. More precisely, the public-private key pairs of DO and DV are (x, X = g x ) ∈ Z * q × G 1 and (y, Y = g y ) ∈ Z * q × G 1 , respectively. Then the DO (resp. DV) can calculate the trapdoor α = H 1 (Y x ) ∈ {0, 1} k (resp. α = H 1 (X y )). For each data block m i ∈ Z * q , compute its tag where F id is the unique identification of the file, and u ∈ G 1 is public. The computations of challenge message chal and returned proof are the same as the ones in our construction. In the final verification algorithm, the DV computes and checks if If it is, then output 1. Otherwise, output 0.

Security analysis
In this subsection, we analyze the security of the IB-DV-PDP protocol presented in the above section.

Theorem 1 If the CDH assumption holds in G 1 , and H 1 , H 2 are seen as random oracles, then the above IB-DV-PDP protocol is secure against any malicious CSP in the random oracle.
Before presenting the detailed proof, we would like to introduce the underlying reasons why the security of IB-DV-PDP can be reduced to the CDH assumption. In particular, given the tuple (g, g a , g b ) ∈ G 3 1 , the algorithm B, who tries to solve the CDH problem, can set P 0 = g a as the master public key since the malicious CSP is not allowed to query the master secret key in the whole query process. The extracted secret key for each user can also be simulated by randomly masking the group element P 0 . The trickiest step is the simulation of tag-generation for each data block, which can be handled by embedding B's another group element g b . Then the auditing query is natural and easy to deal with.
Proof. Let CSP be a PPT CSP, who attacks on the proposed IB-DV-PDP protocol. Consider B as an attacker on the CDH assumption. That is, given the tuple (g, g a , g b ) ∈ G 3 1 , its target is to output the element g ab for the unknown a, b ∈ Z q . Now, B simulates the environment for CSP and wants to obtain its answer by using CSP as a subroutine.
• Initialization. B first generates params as in Setup except for the item P 0 . More precisely, it sets P 0 = g a and implicitly defines the master secret key x as the unknown a. Give params to CSP. In addition, B also initializes an empty list L used to store the query-answer pairs. • Queries. The adversary CSP is allowed to adaptively make the following queries.
Randomly choose x 1 , · · · , x s , r from Z q and compute That is, and implicitly set t = ar. Moreover, define where α i satisfies Here, we know that, for 1 ≤ i ≤ n, it holds that x j m i,j ar = g ab g (ab)(rα i +r x j m i,j ) · g a rβ i = g ab 1+rα i +r x j m i,j · g a rβ i = g a rβ i .
Since both of the proofs and * can pass the verification of (3), it holds that and , g .
Because r, x 1 , x 2 , · · · , x s are random and at least one (M j −M * j ) does not equal to 0, we know that s j=1 rx j (M j − M * j ) = 0 occurs with probability 1/q, which is negligible. Therefore, B can obtain the answer g ab by computing This ends the proof of Theorem 1. As for the security of the DV, we have the following: Theorem 2 If the WDH assumption holds for the bilinear map e : G 1 × G 1 → G 2 , then our proposed IB-DV-PDP protocol is secure for the designated verifier. Now, we first explain the underlying intuition of this theorem's proof. Given the tuple (g, g a , g b , g c ) ∈ G 4 1 , the algorithm B attacking on the WDH assumption can naturally set g a as the master public key P 0 , and g b , g c as the random-oracle queries to H 1 for the identities (2022) 11:7 Page 9 of 14 ID O and ID V , respectively. Then the finding of trapdoor trd = e(g, g) abc for un-designated verifier is just the WDH-solution of B . This is also the reason why WDH assumption is used in this paper.
Proof. Assume that A is an adversary who wants to find out the trapdoor of the DV. Then we will construct another algorithm B attacking on the WDH assumption. In particular, given the tuple (g, g a , g b , g c ) ∈ G 4 1 , B intends to compute and output the element e(g, g) abc ∈ G 2 . Hence, it simulates the environment for A and invokes A as a subroutine.
The simulation of B is similar to that of the algorithm B constructed in Theorem 1. That is, B also sets P 0 = g a , H 1 (ID O ) = g b . Moreover, it defines H 1 (ID V ) = g c . In this way, B can simulate all the queries from A as in the above theorem. Finally, when A outputting trd * as a guess of the trapdoor of DV, B also outputs it as its answer to the WDH assumption.
From the simulation of B , we know that Therefore, if A can correctly find the trapdoor trd, then B is also able to solve the WDH assumption. From the hardness of WDH assumption, we know that our proposed IB-DV-PDP protocol is secure for the DV. This also ends the proof of Theorem 2.
In order to further reduce the communication cost, we suggest the following improvements. Define a new hash function H : {0, 1} * → G 1 . Then generate and define T Fid as the IBS of (R||Fid). In the security proof, the hash function H is still viewed as a random oracle, which provides randomness for u 1 , u 2 , · · · , u s . In this case, the communications of u 1 , u 2 , · · · , u s can be reduced from T. Similarly, they can also be reduced from the returned proof because the DV can compute them on-line from Fid.

Error detection probability
Since our proposed IB-DV-PDP protocol adopts the random sampling method to detect the corruption of user's data, we now discuss its error detection probability for the DV. Specifically, in our protocol, the DV chooses blocks in each challenge. Assume that d blocks are corrupted by CSP and define X as a random variable, which describes the number of challenged blocks matching the corrupted ones. Moreover, P X denotes the probability that CSP's misbehavior is detected. Hence, we have Obviously, the more challenged blocks, the higher error detection probability. If 5,000 blocks out of 1,000,000 ones are tampered, then the error detection probability P X is greater than 80% when challenging 321 blocks (for the DV). Similarly, if 10,000 blocks are corrupted, then randomly choosing only 300 blocks will realize that the error detection probability P X is at least 95%.

Performances analysis
In this section, we evaluate the performances of our proposed IB-DV-PDP protocol from communication overhead, storage and computational costs as well as the experimental result. In order to present the practicality of our protocol, we compare it with two other IB-PDP protocols and a certificateless PDP protocol with privacypreserving property, which were designed in [8] [9], and [4], respectively.

Communication overhead
The communication contents for an IB-PDP protocol include the parts of transmitting the authenticated file T from data owner to CSP, a challenge message chal from the DV to CSP, and the returned proof from CSP to the DV. Now, we respectively denoted by DOtoCSP, DVtoCSP, and CSPtoDV the corresponding communication overheads.
Recall that, in our protocol, the DO will send the authenticated file to CSP. Thus, the communication overhead (i.e. DOtoCSP) for our protocol equals to Similarly, we can evaluate the communication overheads from DO to CSP for the three protocols in [8], [9] and [4] as (n + 2) · |G 1 | + λ + |T Fid |, (n + 1) · |G 1 | + λ + |T Fid |, and n · (λ + |n| + |G 1 |), respectively. The challenge message chal in our protocol is , which has the length of 2 · |n| + |Z * q |. The challengemessage-generation algorithm in [8] is the same as that of our protocol and thus DVtoCSP for this protocol is also 2 · |n| + |Z * q |. In addition, in [9], the challenge message is in which, c 1 , c 2 are in G 1 and G 2 , respectively, i ∈[ n], v i ∈ Z * q , and pf is a proof of knowledge. Therefore, the communication overhead DVtoCSP for this protocol equals to |G 1 | + |G 2 | + · (|n| + |Z * q |) + |pf |. We also know that the challenge message of Ji et al. 's protocol has length of · (|n| + |Z q |).
The total comparisons on the communication overheads are listed in Table 2.

Storage cost
Now, we analyze the storage costs of the chosen protocols. First, in our protocol, there are four entities: KGC, DO, DV, and CSP. In the running of this protocol, the KGC will store its own master secret key msk = x ∈ Z q , which has length of |Z q |. For DO, after outsourcing its original Table 2 The comparisons on the communication overheads
Finally, the DV needs to store its own private key sk V ∈ G 1 and the challenged message chal = ( , k 1 , k 2 ) ∈ [ n] ×Z * q × Z * q , which have lengths of |G 1 | and |n| + 2|Z * q |, respectively. Note that the storage cost of CSP just equals to the communication cost from DO to CSP, which has be discussed in the previous subsection. Hence, we do not consider it in the following parts.
Similarly, we can evaluate the storage costs of the involved entities for other protocols, and present the comparisons in Table 3.

Computational cost (Theoretical analysis)
Now, we analyze the computational cost of our protocol, which mainly consists of the computations of authenticated data file T (for DO), returned proof (for the CSP), and the verification of . The computational cost mainly relies on the expensive operations like pairing, multiplication, and exponentiation, since other operations such as the hash function or addition on group only have negligible costs. For clarity of the theoretical analysis, we denote by T p , T mul , and T exp the computational costs for pairing, multiplication and exponentiation (on group G 1 ), respectively.
First, in our protocol, the generation of the authenticated data file T will need to compute n tags u 1 , u 2 , · · · , u s , R, and T Fid = IBS.Sig(R||Fid). Hence, the computation cost is where T IBS denotes the time-consumption of generating a signature in an IBS scheme. If we set s = 1 as in [8], then the cost is (2n + 2) · T exp + (3n) · T mul + T IBS . Similarly, we can evaluate the computational costs for the authenticated data file T in [8], [9], and [4] as where T S is the time-consumption for a signature algorithm (like BLS-signature), (2n + 1) · T exp + n · T mul + T IBS , and 3n · T exp + 3n · T mul , respectively.
Next, we consider the computational cost of generating the proof . In our protocol, is generated by computing However, the time-consumptions of in [8], [9], and [4] are Finally, the computational costs of verifying for the three protocols are analyzed as follows. In our protocol, the DV will first verify the validity of T Fid , whose time-consumption is denoted by T Ver , and then check the equality (3). The total computational cost is If s = 1, then it is Similarly, we can evaluate the verifications of other protocols and calculate their computational costs as T Ver + 3 · T p + (2 + 2) · T exp + (2 + 1) · T mul , where T Ver denotes the time-consumption for the verification of a signature scheme, T Ver + T p + ( + 1) · T exp + ( − 1) · T mul , and 2 · T p + ( + 1) · T exp + ( + 2) · T mul , respectively.
In addition, we remark that our protocol is the first one for a designated verifier but the other two protocols are not. The total comparisons on the computational costs are listed in Table 4. Table 4 The comparisons on the computational costs

Experimental results
In order to further evaluate the performance of our proposed protocol, we implement it within the framework of "Charm" [27]. In particular, the 512-bit SS elliptic curve from pairing-based cryptography (PBC) library is set as the basis of our experiments [28]. The DO and DV are simulated by a Huawei MateBook with the configuration of Intel Core i5-6200U CPU @2.3GHz and 16GB RAM. Then the CSP is simulated by a Huawei Fusion-Server 2288H V5 with the configuration of Xeor Bronze 3106@1.7GHz, 16GB RAM.
Since, in the three protocols, standard signature or IBS scheme is needed, we choose the BLS-signature [29] and the IBS scheme in [30] or [4] as building blocks to implement them. Now, we choose a data file with size of 500 MB, which is parsed as 100, 200, 300, 400, and 500 blocks. Then the time-consumptions for the generations of authenticated files in the three protocols are listed in Fig. 2. For each authenticated file, we set the numbers of challenged blocks as 30, 60, 90, 120, and 150. Then the time-consumptions for the generation of returned proof and the verification for DV are presented in Fig 3 and 4, respectively.
From the comparisons of experimental results, we can see that our proposed protocol is competitive especially for the generation of the returned proof. However, we still explain that our protocol is the first one for the DV but the other ones are not. Hence, our protocol does not obviously reduce IB-PDP's efficiency, and can be naturally used in future real-life applications.

Conclusions
In many practical scenarios, the data owner only hopes some designated verifier to perform the auditing task, which is not covered by private or public auditing model. Yan et al. recently designed an auditing protocol with a designated verifier to resolve this problem. But their protocol naturally suffers from complicated management of certificates and heavy dependence on PKI. In this paper, for the first time, we introduce the identity-based remote data checking with a designated verifier. Compared with the existing PDP protocol with a designated verifier, our protocol avoids the introduction of PKI and management of public key certificates. Moreover, we also give the security model and prove that our protocol is provable secure based on the CDH and WDH assumptions in the random oracle model. The final analysis on performance shows that this protocol is also efficient and can be used in future real-life applications. Future works. The first interesting problem is how to design more efficient IB-DV-PDP protocol so that it can find applications in practical scenarios. In addition, note that the security of our proposed IB-DV-PDP protocol relies on the ideal random oracle, and thus the second future work is finding and designing an efficient IB-DV-PDP protocol, which is provable secure in the standard model.