Identity-Based Public Auditing Scheme for Cloud Storage with Strong Key-Exposure Resilience

the


Introduction
Cloud storage is one of the services provided by the cloud, where a client can store data in the data centre managed by the Cloud Service Provider (CSP). To deal with the hardware, software, and maintenance challenges of data growth and its associated costs, many enterprises are moving their business-critical data and applications to the cloud [1][2][3][4].
ere is an increased adoption of public cloud [5] mainly to reduce the cloud cost. Even though the CSPs guarantee that the stored data will be secure and intact, many issues affecting the confidentiality, integrity, availability, etc. of the stored information [6] are likely to happen in the cloud. Among them, integrity is considered to be critical as the cloud client does not have physical control over stored data. For the same reason, traditional integrity checking mechanism cannot be directly applied to cloud storage. Downloading all the data and verifying them periodically would result in high communication costs and time.
erefore, checking the integrity of the cloud data remotely is truly a security challenge for cloud clients.

Issues in Cloud Storage
Auditing. Data integrity is the overall completeness, accuracy, and consistency of data, i.e., the data stored in the cloud is not altered or deleted without the client's knowledge. Ateniese et al.'s auditing model for Provable Data Possession (PDP) at untrusted stores [7] is widely used for cloud data integrity checking. In this model, the cloud client divides a data file into blocks, generates an authentication tag for each block using a secret key called the auditing secret key, and then uploads the data blocks and the authentication tags to the cloud. During audit, a challengeresponse protocol is used between the client and the CSP, wherein the client verifies a small number of random set of data blocks without downloading them. is type of verification is called blockless verification. is feature facilitates the client to outsource the data auditing to a ird Party Auditor (TPA), and this type of auditing is called public auditing.
Most of the PDP-based auditing schemes use Public Key Infrastructure-(PKI-) based cryptography, Identity-based cryptography, etc. PKI-based auditing systems [10][11][12][13][14][15][16][17][18] have communication and computational complexities of certificate management and certificate verification [19]. Identitybased auditing schemes [19][20][21][22][23][24][25] improve the efficiency by eliminating the use of certificates but have some limitations such as key exposure, computational overhead of dynamic data updates, etc. Further, some of these schemes do not provide support for simultaneous auditing of cloud data of multiple clients which is called batch auditing. Batch auditing reduces the computation time of the TPA in auditing the data of multiple clients.
Exposure of the auditing secret key of a cloud client is a serious problem since the integrity of data cannot be assured.
ere are many ways in which the auditing secret key is exposed. Improper key management can lead to key exposure [28]. Even a semitrusted CSP may try to conceal the data loss events caused by Byzantine failures etc. from the clients [28] in order not to lose business. e CSP may attempt to steal the auditing secret key of the client, generate fake data, and also valid authentication tags that may go unidentified during audit. Some cloud clients may update the data in the cloud and regenerate the data block tags using mobile devices [29] that have resource constraints. ese devices are not secure and are therefore prone to key exposure. Once the auditing secret key is exposed, all the data block tags, irrespective of whether they were generated before or after the exposure become invalid, resulting in loss of data integrity.
Most often, key exposure is unknown and also difficult to detect. erefore, it is necessary to be proactive in minimizing the damage caused by key exposure even before knowing that such an exposure has happened. Minimizing the damage caused by auditing secret key exposure means that the attacker is unable to forge any of the data block tags, even after acquiring the key. e existing Identity-based cloud auditing scheme [26] tackles the auditing secret keyexposure problem with the forward security property [27] where the secret key evolves over time. With forward security, the authenticators generated using the secret keys of time periods earlier to the time period of the exposed secret key could be preserved. e authenticators of remaining time periods, i.e., the authenticators generated using the exposed key and those generated from the secret keys of time periods later to the time period of the exposed key could be forged [15].
is is because the adversary can derive the future auditing secret keys from the exposed one. Considering these facts, this research focuses on minimizing the impact of damage to the data integrity in time periods both earlier and later to the time period of the exposed key in Identity-based cloud storage auditing schemes.

Literature Survey.
Some of the research works on the issues of auditing secret key exposure in cloud storage auditing and minimizing the problems due to the key-exposure are reviewed in this section.
Provable Data Possession (PDP) [7] and Proofs of Retrievability (PoR) [8,9] are the two models used to check the integrity of data outsourced to untrusted and remote servers without actually downloading the data. ese models use the technique of random sampling to audit the data. e PoR model uses error correcting codes to recover corrupted portions of the data file. e cloud auditing schemes are either based on PDP or PoR. PDP is the widely used model [10-26, 28, 29].
e Public Key Infrastructure-(PKI-) based cloud auditing schemes in [15][16][17]28] provide key-exposure resilience. e scheme in [28] is forward secure. e auditing secret key of the schemes given in [15,16] is jointly updated by both the client and the TPA, and it is both forward and backward secure. So, only the authenticators which were generated using the exposed secret key can be forged. e intrusion resilient scheme in [16] divides a time period into several refreshing periods and refreshes the secret values (that are used to update the auditing secret key) in each refreshing period. erefore, the adversary can compute the auditing secret key of the client only if the client and the TPA are compromised in the same refreshing period. e scheme in [17] encrypts the auditing secret key and outsources the updation of the encrypted key to the TPA. e schemes in [16,17,28] use a binary tree for key updation. erefore, these schemes do not support unbounded time periods and the key update time is not constant, it varies depending on the location of the node (associated with the current time period) in the tree. e number of exponentiation operations in the ProofVerify algorithm of the schemes in [17,28] is dependent on the bit length of the node corresponding to the time period of integrity verification. e key update time in the scheme in [15] is constant, and it supports unbounded time periods. e PKI-based key-exposure resilient schemes do not provide support for batch auditing [18]. e computation time of data integrity verification is high and is also linear to the number of data blocks challenged to the cloud server. ese schemes also require checking the validity of public key certificates of cloud clients incurring extra computation and communication costs to the verifier. erefore, to eliminate certificate verification, Wang et al. proposed the Identity-based cloud storage auditing scheme [19] where a third party called the Private Key Generator (PKG) generates the client's auditing secret key from the master secret key of the PKG and the identity of the client. e identity (ID) can be the e-mail address or the IP address of the client. Wang also proposed an Identitybased auditing scheme for multicloud storage [20]. e Identity-based scheme with perfect data privacy [21] realizes zeroknowledge privacy against the ird Party Auditor (TPA). e Identity-based proxy oriented cloud auditing scheme [22] achieves private verification, delegated verification and also public verification. e Identity-based public auditing scheme in [23] provides efficient batch auditing. e Identity-based auditing scheme of Zhang et al. [24] for shared data provides efficient user revocation. In this scheme, the manager and the members of the group share the public key and the auditing secret key. e manager and the non-revoked group users update the secret key whenever a group member gets revoked.
e Fuzzy Identity-based scheme [25] uses the biometric data of the client as the client's identity for improved security. is biometric-based identity increases the computational cost of the cloud client, the cloud server, and the TPA. Many of these Identity-based schemes do not consider the auditing secret keyexposure. e Identity-based scheme in [26] is a lattice-based cloud auditing scheme and provides only forward security. It shows that the auditing secret key exposure is a critical issue in cloud storage auditing and needs to be handled efficiently.

Objectives of the Work.
In the study of the current research on the key exposure issue of cloud storage auditing, it is observed that the following aspects need to be focused on while proposing any mechanism to handle data integrity with acceptable performance.
(1) Generally, trust is a critical issue with Cloud Service Provider (CSP). Auditing secret key exposure is a critical problem and it exists in Identity-based cloud auditing systems. It is practically difficult to prevent key exposure. Existing Identity-based solution provides only forward security and must be improved further to control the impact of auditing secret key exposure. Moreover, the solution for the critical problem should not largely affect the computation time of verifying the data blocks. (2) Auditing is a complex task for any client. Generally, the client delegates the auditing process to the ird Party Auditor (TPA). In this case, it is necessary to ascertain that the content of the stored data should not be known to the third party. (3) e TPA can have auditing jobs from multiple clients. Auditing jobs one by one is time consuming since it involves considerable amount of computation. So it is indispensable to use suitable mechanism to improve the efficiency of auditing.
Hence, the primary objective of this work is to propose a PDP-based auditing scheme to protect the security of Identity-based cloud storage auditing in time periods both earlier and later to the time period of the exposure of auditing secret key and also to provide support for batch auditing.

Contributions.
is research focuses on the above aspects of auditing in the public cloud. e contributions of this work are listed as follows: (1) An Identity-based cloud auditing scheme is proposed using bilinear pairings. e scheme is based on the PDP model. e scheme provides both forward and backward security. Hence, it is strongly resilient to auditing secret key exposure, and the security of cloud storage auditing is protected both earlier and later to the time period of the exposed key. e lifetime of a data file, to be stored in the cloud, is divided into T time periods, and the auditing secret key is jointly updated in each time period by both the client and another entity at the client's end. Key update time is constant, and the number of time periods is unbounded so that the execution time of the algorithms is independent of T. e public keys remain fixed. e scheme does blockless verification with significant reduction in the computation time.
(2) e intractability of solving the discrete logarithm problem and the frequent monitoring of audit reports by the client help to ensure that the TPA acquires nothing from the stored file. (3) e scheme is extended to include batch auditing. It enables the TPA to audit data files of multiple clients simultaneously, thereby improving the efficiency of auditing further. e rest of the paper is structured as follows: Section 2 discusses the system model, the security model, and the preliminaries. Section 3 explains the proposed scheme in detail. In Sections 4 and 5, we demonstrate the security analysis and the performance analysis of the proposed scheme followed by the conclusion in Section 6.

Models and Definitions
is section provides the system model, the definition of the strong key-exposure resilient cloud auditing scheme, the security model, and the preliminaries which are used in the system.

System Model.
A basic Identity-based cloud auditing model comprises of the cloud server, one or more cloud clients, the PKG, and the TPA. e cloud server has huge storage capability and stores the data of cloud clients. e PKG is usually a third party. e PKG generates the system parameters, the master secret key, and the system public key. e PKG computes the auditing secret key of the client from the "ID" of the client. e cloud client divides the data file into data blocks of fixed size and generates an authentication tag for each data block using the auditing secret key obtained from the PKG. e client then uploads the data blocks and the tags to the cloud and then deletes them from the local machine. During audit, the TPA sends an audit challenge to the cloud server and verifies the audit response. Audit reports are sent to the clients for review. Figure 1 illustrates the proposed System Model. In this model, the cloud server is considered to be a Public Cloud Server (PCS). e PKG is presumed to be a server in the IT department of the enterprise. e cloud clients are assumed to be the employees of the enterprise who are entrusted to store the corporate data in the PCS. In the proposed design, all cloud clients have two secret keys, the Audit key and the Time key. e auditing secret key is called the Audit key, "sk u,t ." It is different for each client. e additional secret key, the Time key "sk h,t " is used to aid in strong key-exposure resilience. It is also different for each client. It may be assumed that each cloud client is responsible for a single file. Each file F is divided into n number of fixed-size data blocks, e lifespan of the file is divided into discrete time periods 0, 1, 2, . . .. . .. e two secret keys are updated in each time period. e public keys remain fixed. e PKG computes the Audit key of all the clients only for time period "0". In addition to the entities mentioned above, the proposed model encompasses one more entity called the Key update server. e purpose of this server is to generate the Time key of all the clients for all the time periods. e Audit key of a client of a particular time period is updated by the client using the Time key of the corresponding time period. To authenticate the data blocks of a time period, the client uses only the Audit key of that particular period. e TPA in the proposed model performs both single-client auditing as well as batch auditing.

Definitions and Security Model
Definition 1 (Strong key-exposure resilient cloud auditing protocol). e proposed strong key-exposure resilient cloud auditing scheme consists of the following algorithms: : is algorithm is run by the PKG. e algorithm takes the security parameter k and sets up the system parameters. It sets the secret key x and the public key pk s of the PKG called the master secret key and the system public key, respectively. Also computes the key update server's secret key y and the key update server's public key pk h . Both pk s and pk h are included in the public parameter, params.
(ii) InitialAuditKeyGen (params, x, y, ID) ⟶ (sk u,0 ): e algorithm generates sk u,0 , which is the Audit key for the initial time period from the identity ID of the cloud client using params, x and y. It is run by the PKG. (iii) TimeKeyUpdate (params, y, ID, t) ⟶ (sk h,t ): At the beginning of time period t, this algorithm updates the Time key sk h,t of a cloud client with identity ID and secret key y and sends it to the client over a secure channel. It is run by the key update server.
is algorithm is run by the client. It generates the Audit key sk u,t for the current time period t from the Time key of the current time period sk h,t and the Audit key of the previous time period sk u,t− 1 and then deletes the keys sk h,t and sk u,t− 1 .
(v) TagGen (params, F, ID, t, sk u,t ) ⟶ (F, σ 1 ,. . ., σ n , t, R): is algorithm is run by the cloud client. It generates the authentication tags for a set of data blocks of file F in time period t using the audit key sk u,t of time period t. For each data block m i of file F, the authentication tag is a pair (σ i , t). e Audit key of time period "0" is sk u,0 . It is computed by the PKG during system setup. It is generally not used to authenticate data blocks. FT is the file tag of F.
ProofGen, this algorithm is run by the PCS. {F k } is the set of files of all the cloud clients. For each client k, the algorithm generates the audit proof corresponding to the audit challenge (chal k , t k ), from file F k and its respective authenticator set Φ k . en the audit proofs of all the cloud clients are aggregated into a single audit response P and sent to the TPA.
is algorithm is run by the TPA to verify the audit response P generated by the BatchProofGen algorithm. Like ProofVerify, the algorithm returns 1 if the verification passes and 0 if the verification fails.
In the security model, the Private Key Generator (PKG) is considered to be a reliable body and the ird Party Auditor (TPA) is presumed to be a true and inquisitive entity. e TPA executes the auditing jobs sincerely and is also curious to know about the data. e cloud clients are considered to be partially trusted, i.e., some of the cloud clients may try to forge the authenticators of others.
e Cloud Service Provider (CSP) is assumed to be a semitrusted party, i.e., the CSP does not have intentions to delete or alter the data, but some inevitable data loss incidents may trigger to do so in order not to lose fame and popularity. e proposed cloud auditing scheme has the following security properties: (i) Correctness: If all the authentication tags in the audit response (corresponding to the audit challenge) are valid, then the audit response will always pass the verification. Hence, even if the Audit key of a particular time period is exposed, the adversary will not be able to obtain any of the earlier or future Audit keys without the corresponding Time key. erefore, the scheme is strongly resilient to key exposure, and the adversary will not be able to forge the data block tags that are generated earlier or later to the time period of the exposed key. (iii) Resistance to replace attack: e CSP may try the replace attack, where the PCS swaps a corrupted data block and its tag (m j , σ j ) in the proof with a valid data block and tag (m l , σ l ) and try to cheat the auditor. Such a proof will fail during verification due to the usage of collision-resistant hash function. (vi) Privacy preserving: Audit of cloud data does not reveal the content of stored data to the TPA. e hardness assumption of discrete logarithm problem and the insertion of random coefficients in the audit challenge/response help to achieve this property.
In order to validate the security for strong key-exposure resilience, a Tag-Forge game is defined as follows: Tag-Forge game: e game is played by two entities, the adversary A and the challenger C. e game consists of three phases, the Setup phase, the Query phase, and the Forgery phase. Setup phase: Here, the challenger takes the security parameter "k" and sets the master secret key x, the key update server's secret key y, and the public parameters "params." It sends params to "A." e secret keys are kept confidential. Query phase: Once the system setup is over, A enters into the next phase called the Query phase where A queries C and C answers A. In this phase, A is allowed to query the H 1 and the H 2 oracles. A can also query the Audit key of any cloud client-the Audit key of initial time period and also the Audit keys of other time periods. A can also query the authentication tag of any client's data block.
For any client i, A can query the following oracles with respective inputs: (i) e H 1 and the InitialAuditKey oracles with the input ID i (ii) e H 2 and the Auditkey oracles with the input (ID i , t i ) (iii) e TagGen oracle with the input (ID i , t i , m il ) A is not allowed to query the Time Key of any client for any time period. A is also not allowed to query the Audit Key of time period t * of a client of identity ID * . For the client with identity ID * , the computation of the Audit key of time period t * requires the Time key of time period t * and the Audit key of previous time period (t * − 1). Even if the adversary has the Audit key of (ID * , t * − 1), the adversary will not be able to compute the Audit key of (ID * , t * ) without the Time key of (ID * , t * ). So the adversary will not be able to generate valid authentication tags for the data blocks of time period t * which is later than time period t * − 1 (backward security).
Forgery phase: After A is finished with its intended set of queries, the Forgery phase is entered. Here, C challenges A with a data block m * of a client of identity ID * and time period t * such that (1) (ID * , t * ) was not used earlier by A in AuditKey queries (2) (m * , ID * , t * ) was not used by A for TagGen queries A computes a proof (σ * , R * , t * ) and wins the game only if (σ * , R * , t * ) is a valid authentication tag on data block m * for time period t * .
Definition 2 (Strong key-exposure resilience). A cloud auditing protocol is said to be strongly resilient to key-exposure, only if the probability with which the adversary A (Cloud) wins the Tag-Forge game is negligible.

Preliminaries
(i) Bilinear Map e bilinear map is used to verify the correctness of the audit response. Let G 1 and G 2 be two multiplicative cyclic groups of same prime order q.
e map e: G 1 × G 1 ⟶ G 2 is called a bilinear map [30], if it satisfies the following properties: (a) Bilinearity: for all s, t ϵ G 1 and a, b ϵ Z * q , e(s a , t b ) � e(s, t) ab (b) Nondegeneracy: there exists g1, g2 ϵ G 1 such that e(g1, g2) ≠ 1 (c) Computability: for all s, t ϵ G 1 one can compute e(s, t) ϵ G 2 in polynomial time (ii) CDH problem Given (g, g a , g b ), where g is a generator of multiplicative group G 1 with order q, and a, b ϵ Z * q , the CDH problem [30] is to compute g ab . e CDH assumption is that it is computationally intractable to compute g ab . It is used in security analysis, for the implication of strong key-exposure resilience.

Description of the Proposed Cloud
Auditing Scheme e proposed strong key-exposure resilient cloud auditing scheme uses the system model and the bilinear map presented above in Section 2.
e scheme uses the key update technique of Wu et al.'s general signature scheme [31] and is extended to support blockless verification of random sets of data blocks which is a key feature of cloud auditing. e algorithms of the proposed scheme are described below:

Security and Communication Networks (i) Setup
(1) Given the input parameter k, the PKG selects two multiplicative cyclic groups G 1 , G 2 such that G 1 and G 2 are of large prime order q and q > 2 k . (2) e PKG then selects a symmetric bilinear map, e: G 1 × G 1 ⟶ G 2 . (3) Define three cryptographic hash functions, H 1 , e PKG randomly selects x, y ϵ Z * q and computes pk s � g x ϵ G 1 and pk h � g y ϵ G 1 .
Here, g and u are two generators of G 1 . x is the master secret key of PKG and pk s is the corresponding system public key. y and pk h are the secret and public keys of the key update server, respectively. (5) e PKG then publishes the public params (G 1 , G 2 , e, g, u, H 1 , H 2 , H 3 , pk s , pk h ).

(ii) InitialAuditKeyGen
(1) Let the initial time period be "0" (2) Given a client's identity ID ϵ 0, 1 { } * , the PKG computes sk u,0 which is the Audit key of the client for initial time period as (3) sk u,0 is then sent over a secure channel to the cloud client (4) e cloud client receives the key and validates it using e g, sk u,0 � e pk s , H 1 (ID) e pk h , H 2 (ID ‖ 0) . (2)

(iii) TimeKeyUpdate
(1) At the beginning of time period t, the key update server updates the Time key, sk h,t using (2) is Time key is forwarded over a secure channel to the client (3) e cloud client checks the validity of the Time key using (iv) AuditKeyUpdate (1) e cloud client computes the Audit key sk u,t for time period t using the time key of the current time period sk h,t and the Audit key of the previous time period sk u,t− 1 : (2) e client then deletes both sk h,t and sk u,t− 1

(v) TagGen
(1) e client picks r ϵ Z * q at random and computes R � g r ϵ G 1 (2) For each data block m i ϵ Z * q of time period t, the client computes the hash value h i : (3) e client then computes the data block tag σ i using the Audit key sk u,t .
(4) e client then uploads the file F, the file tag FT � file name ‖ n ‖ t ‖ Sign sk ( _ f) and all the authentication tags Φ � {σ 1 , . . . ,σ n , t, R} to the PCS. Here, Sign is a digital signature on _ f and _ f � (file_name‖n‖t). sk and pk are the secret key and the public key associated with Sign [15]. (5) e PCS validates each data block tag as e g, σ i � e R m i , u e pk s , H 1

(vi) ChallengeGen
(1) e TPA checks whether the file tag FT is valid by checking the validity of Sign sk ( _ f) using the public key pk.
(2) If it is not valid, the TPA reports to the client. (1) e PCS on receiving (chal, t) computes the coefficient v i ϵ Z * q for each data block i ϵ I using v i � l i mod q (2) It then aggregates the authenticators of all block indices involved in the challenge, (1) On receiving the audit response P from the PCS, the TPA computes h i � H 3 (ID‖t‖i) for i ϵ I (2) e TPA then verifies whether e(g, σ) � e R 1 , u e pk s , H 1 If verified, returns true and false otherwise. e proof of correctness is presented below.
Proof of correctness: Since the above equation holds, the valid proof can be accepted.
Batch auditing is incorporated in the proposal by modifying the above ProofGen and ProofVerify algorithms to support multiple clients. ese algorithms after modification are called BatchProofGen and BatchProofVerify, respectively. In these algorithms, let K be the set of cloud clients of firm "A" and client k ϵ K. ID k is considered to be the identity of cloud client k. For each client k, the algorithms InitialAuditKeyGen, TimeKeyUpdate, AuditKeyUpdate, TagGen, and Challenge-Gen are the same as given above. e g, σ * � e R * , u e pk s ,

Security Analysis
e security proofs for the audit response in batch auditing are similar to the audit response in a single client setting. Hence, in this section, the audit response in a single client setting is considered for analyzing the algorithms of the Security and Communication Networks proposed scheme. Here, some theorems are formalized and proofs for the same are presented.

Theorem 1 (Strong key exposure resilience). If the CDH assumption holds in bilinear group G 1 , then the proposed
Identity-based cloud auditing scheme is strongly resilient to key exposure.
Proof. Consider G 1 to be a multiplicative group of prime order q . Let g be a generator of G 1 and a, b ϵ Z  * q . e CDH problem is to compute the value of g ab , given the values of g, g a , and g b . e proof for the theorem is established using the Tag-Forge game explained in Section 2. e game is played by two entities, A and C. Here, A is an adversary and C is the challenger. If A wins the game with nonnegligible probability ϵ, then C can solve the CDH problem.
In this game, H 1 and H 2 are considered to be random oracles and H 3 is considered as a one-way function with collision-resistance. C maintains the lists H 1 , H 2 , L 1 , L 2 , and T, which are initially empty. For any query on Ini-tialAuditKey or AuditKey or TagGen oracle on identity ID i of a cloud client for time period t, a H 1 query is assumed to be already been made on that identity.
(i) Setup: Let G 1 and G 2 be two cyclic multiplicative groups of prime order q. C sets pk s � g a as the public key of PKG and pk h � g y as the public key of key update server. C randomly chooses t ϵ Z * q and sets u � g t (t is different from time periods t i and t * ). C returns (G 1 , G 2 , e, g, u, q, pk s , pk h ) to A. (1) If c � 0, B randomly picks m ϵ Z * q to set In both the cases, C adds (ID i , c, h i1 , m) to the H 1 list and returns h i1 to A.
where t i is time period, C returns the corresponding value if the H 2 list contains an entry for (ID i , t i ); otherwise, C selects an integer n ϵ Z * q randomly, computes H 2 (ID i ‖ t i ) � g n ϵ G 1 , and adds (ID i , t i , n, g n ) to the list and also returns g n to A. (iv) InitialAuditKeyQuery: When A queries C with input ID i , C returns the value sk u,0 if a tuple matching the input ID i exists in the L 1 list. If the ID i is not found in the list, then C retrieves the tuple (ID i , c, h i1 , m) from the H 1 list and responds as follows: (1) If c � 0, C computes sk u,0 � pk m s � (g a ) m ϵ G 1 , adds (ID i , sk u,0 ) to the list L 1 and returns sk u,0 to A.
(v) AuditKeyQuery: For the input (ID i , t i ), C retrieves the tuple (ID i , t i , sk u,t ) from the L 2 list and returns sk u,t to A. If such a tuple does not exist, then the tuple (ID i , c, h i1 , m) is retrieved from the H 1 list.
(1) If c � 0, C retrieves the tuple (ID i , t i , n, g n ) from the H 2 list, computes sk u,t � (g n ) y . (g a ) m ϵ G 1 to A, adds (ID i , t i , sk u,t ) to the list L 1 , and returns sk u,t to A. (1) If c � 1, C outputs a failure message and aborts.
(2) If c � 0, C proceeds to compute the tag for block m il . C randomly selects k ϵ Z * q to compute e output (σ il , R, t i ) is a valid authentication tag for data block m il . It is added to the T list and is also returned to A.
(2) If c * � 1, C proceeds to find the value of g ab e g, σ * � e R * m * , u e pk s , where Let us assume that A makes Q e , Q c , and Q t queries, which are InitialAuditKey, AuditKey, and TagGen queries, respectively.
e success probability of C depends on the following five events: Event 1 : C does not halt due to any of A's Ini-tialAuditKey Queries Event 2 : C does not halt due to any of A's AuditKey Queries Event 3 : C does not halt due to any of A's TagGen Queries Since the above is a contradiction to the CDH assumption, it is impossible to forge the authentication tag. Hence, it is concluded that the proposed Identity-based scheme is a strong key exposure resilient cloud auditing scheme. □ Theorem 2 (Resistance to replace attack). e proposed cloud auditing scheme can resist the replace attack of the PCS.
Proof. Let's say that a challenged data block m j and/or its authentication tag σ j is corrupted. e PCS uses a valid (m l , σ l ) instead of (m j , σ j ) in the proof since (m j , σ j ) will not pass the auditing. e PCS sends the proof P � e above verification will pass only if h l − h j � 0. Since H 3 is a collision-resistant hash function h l − h j ≠ 0, the verification will fail. □ Theorem 3 (Privacy preserving). e curious TPA will not be able to get the data stored in the PCS or any information about the data. Proof.
e TPA receives the proof message, P � {R 1 , t, σ} where R 1 � R Σ i∈I(m i v i ) and σ � i∈I σ v i i , from the PCS. Let us consider v i to be a variable and m i to be a constant in the linear equation Σ iϵI (m i v i ). Even though the TPA knows the value of all the variables, he will not be able to compute the value of one or more constants since there are more than 100 variables in a single linear equation. e client also monitors the audit report and ensures that subsequent challenges do not contain the same set of block indices. Moreover, even if the TPA comes to know about the value of R m i , it is impossible to compute m i due to the intractability of solving the discrete logarithm problem. So the TPA will not be able to gain any information about the cloud data from the proof message.
From the above theorems, it is shown that the proposed cloud auditing scheme is an Identity-based strong key exposure resilient auditing scheme and it is resistant to the replace attack of the PCS. Also, the TPA will not be able to collect any information from the data file during audit. □ e schemes in [15,17] are key-exposure resilient PKI-based schemes. e scheme in [24] is an Identity-based scheme for shared data with efficient user revocation.

Analysis of the Data Storage Size and the Size of Audit
Messages.
e numerical analysis of the size of the data stored on the cloud server and the size of audit messages used for communication between the cloud server and the TPA is presented in Table 1 for all the four schemes. e size of the audit response message in batch auditing is given in Table 3 for the proposed scheme. e file and its associated set of authentication tags (one tag per data block of the file) are stored in the cloud server. erefore, the size of the authentication tags is also included in the measurement of      the amount of data storage in Table 1. In the tables, |F| denotes the size of a file F, n represents the number of data blocks of F, and |i| is the size of a data block index. |G 1 | and |Z q | denote the size of an element of G 1 and Z q , respectively. c represents the number of data blocks challenged to the cloud server, |t| is the size of a time period, RN is the number of user revocations, and |RN| represents its size. It is seen from Table 1 that the size of an audit challenge message in the proposed scheme is smaller than the other three schemes. Table 2 gives the numerical analysis of the computation time of all the four schemes. e computation time of the proposed scheme in batch auditing is given in Table 3. In Table 2, bl is the bit length of a node in the binary tree in [17]. T H , T e , T p , T inv , and T m denote the execution time of a hash to a point in G 1 , exponentiation in group G 1 , pairing from G 1 to G 2 , inverse in G 1 , and multiplication in G 1 , respectively. Other operations such as set operations, operations in the group Z q , are omitted in the tables as they contribute negligible computation time.

Analysis of Computation Time.
All the four schemes are simulated and tested on Ubuntu Linux 17.04 with Intel(R) Core(TM) i5 CPU 650 @ 3.20 GHz and 4.00 GB RAM. For cryptographic operations, Pairing-Based Cryptography (PBC) Library version 0.5.14 [32] and a bilinear map that uses a supersingular elliptic curve are used. In all the schemes, |G 1 | � 128 bytes and |Z q | � 20 bytes. |F| and n are assumed to be 20 MB and 1,000,000, respectively, as the schemes in [15,24]. e probability of error detection is determined by the number of data blocks challenged by the TPA. Let us say that s out of n blocks are bad, i.e., corrupted or deleted. e error detection probability is 100%, if all the n blocks are challenged. If c out of n blocks are challenged, then the detection probability is With c � 300 blocks and s � 1% of n, P(300) is at least 95%. e graph in Figure 2 gives the time taken to update the auditing secret key. It is seen that the key update time of Scheme (2018) is much lesser than all the other schemes during some of the user revocations. e purpose of key updation of Scheme (2018) also differs from that of all the other schemes. Scheme (2016), Scheme (2017), and the proposed scheme update the secret key in each time period to achieve resilience to key exposure. Scheme (2018) updates the secret key to revoke a group user. In Scheme (2018), the RN variable is initially set to 0 and the auditing secret key is jointly generated by the PKG, the group manager, and the group users. During each user revocation, the RN variable gets incremented by 1 and the group manager and the nonrevoked group users update the auditing secret key. e key update time is higher for RN � 0 (2T e ) than for RN > 0 (T e ). In Scheme (2016), the secret key is updated by the TPA using a binary tree, and therefore, the key update time is 0.011 seconds for the internal nodes of the tree (time periods 0, 1, 2, 5, 8,9) and 0 seconds for the leaves of the tree (time periods 3, 4, 6, 7, 10). In Scheme (2017), the audit key is jointly updated by both the client and the TPA. In the proposed scheme, it is jointly updated by the key update server and the client. In the proposed scheme, the key update time for the initial time period is (2T H + 2T e + T m ) and is higher than the remaining time periods due to the additional T e . A single T e is greater than T inv + 2T m . Figure 3 shows that the time to generate authentication tags in the proposed scheme is lesser than all the other schemes. It is because the tag generation algorithm of the proposed scheme does not have any hash to a point in G 1 operation. It is seen from Figure 4 that the audit response/ proof generation time is almost similar for all the schemes. In Figure 5, the Proof verification time of the proposed scheme is constant irrespective of the number of data blocks. It is also very less when compared to the other schemes due to significantly less number of hash to a point in G 1 and exponentiations in G 1 . Figures 6 and 7 show that in batch  The number of clients

Conclusion
e need to preserve the integrity of data stored in the cloud rises with the growing demand for storage-as-a-service offering of cloud. So cloud storage auditing schemes are designed to verify the possession of cloud data but there are critical issues in these auditing schemes. is paper studies the auditing secret key exposure problem in Identity-based cloud storage auditing schemes. Since exposure of secret key is undetectable, a better way to handle the key exposure problem is to minimize the damage caused by the exposed key. An Identity-based strong key-exposure resilient cloud auditing scheme using bilinear pairing is designed and implemented. e proposed scheme preserves the security of cloud auditing both before and after the key exposure by forward and backward security mechanism. Batch auditing is also incorporated into the scheme to ease the workload of the auditor. e scheme is provably secure using the computational Diffie-Hellman assumption in the random oracle model. Experimental results show that the proposed scheme is efficient in auditing the data blocks.

Data Availability
No data were used to support this study.

Conflicts of Interest
e authors declare that they have no conflicts of interest.