Identity-based Provable Data Possession for Multicloud Storage with Parallel Key-Insulation

Abstract

Cloud Storage is the primary component of many businesses on cloud. Majority of the enterprises today are adopting a multicloud strategy to keep away from vendor lock-in and to optimize cost. Auditing schemes are used to ascertain the integrity of cloud data. Of these schemes, only the Provable Data Possession schemes (PDP) are resilient to key-exposure. These PDP schemes are devised using Public Key Infrastructure (PKI-) based cryptography, Identity-based cryptography, etc. PKI-based systems suffer from certificate-related communication/computational complexities. The Identity-based schemes deal with the exposure of only the auditing secret key (audit key). But with the exposure of both the audit key and the secret key used to update the audit key, the auditing process itself becomes a complete failure. So, an Identity-based PDP scheme with Parallel Key-Insulation is proposed for multiple cloud storage. It reduces the risk of exposure of both the audit key and the secret key used to update the audit key. It preserves the data privacy from the Third Party Auditor, secure against malicious Cloud Service Providers and facilitates batch auditing. The resilience to key-exposure is proved using the CDH assumption. Compared to the existing Identity-based multicloud schemes, it is efficient in integrity verification.

1. Introduction

Cloud storage has become a vital resource. Several enterprises are moving to cloud for business related data storage and applications. The need has massively increased these days due to the COVID-19 pandemic [1]. AWS, Azure, Dropbox, Google Drive, IBM Cloud are some of the prominent Cloud Service Providers (CSPs) who are serving enterprises. To deal with data growth and vendor-lock in, to optimize cost and performance [2,3], many large enterprises adopted a multicloud strategy which can be multiple public or multiple private or hybrid cloud. Some of them store sensitive data such as business plans, financial records etc. even in public clouds. Despite the benefits of multicloud storage, there are challenges of confidentiality, integrity, availability etc. Of all the challenges, data integrity [4] is the principal focus of cloud clients since loss of data can damage the business of the client.

1.1. Auditing

The integrity of cloud data is affected by many factors, which may be accidental or intentional [5]. Hardware/software failures, human errors and misdeeds can damage the data. So, it is the duty of the cloud clients to audit the data periodically [6] and ensure that it is neither altered nor deleted. Most of the schemes for cloud data auditing use the Provable Data Possession (PDP) model [7]. This model eliminates the download of actual data from the cloud called blockless verification. Blockless verification reduces the communication cost of data download.

To enable auditing, each data block stored in the cloud has an authentication tag signed using the client’s secret key called the auditing secret key or the audit key. Exposure of the audit key is a critical issue since it forsakes the purpose of auditing itself. Both the semi-trusted CSP and the malicious CSP may try to acquire the key. Enterprises also run through the security risk of managing cryptographic keys. With the key, a semi-trusted CSP can attempt to hide from the client, the unforeseen failures like data loss inorder to avoid losing status and profits. A malicious CSP may intentionally delete the infrequently accessed data to allure additional clients and still successfully pass during the audit [8]. Key disclosure is mostly undetectable or detected only after some serious impairment. It is also unavoidable. So, it is necessary to minimize the impact of key- exposure even before being informed about the exposure.

The audit key exposure issue is handled in some of the PDP schemes (Public Key Infrastructure (PKI-) based schemes and Identity-based schemes) for single cloud storage. In these schemes, the audit key evolves over time i.e., the lifetime of the data file is partitioned into time periods and the audit key is updated at the beginning of time periods [8-15]. Some of these schemes are secure in the preceding time periods of the exposed key (forward security). The remaining schemes are secure in both the past and the future time periods of the exposed key (forward and backward security). The PKI-based schemes [8-13] use public key certificates. So, there are communication cost and computational overhead of certificate management/verification especially in the data audit of multi-clients, which is the case of enterprise storage. These schemes still face the key-management problem. The Identity-based key-insulated scheme [15] is both forward and backward secure. In this scheme, the audit key is updated together by both the key updating server and the client. The secret key of the key updating server (we will call it update key for our reference) which is obtained from the PKG and which is used to update the audit key, remains unchanged in all the time periods. The scheme [15] assumes that this update key is secure. If both the update key and the audit key of a time period are exposed, then the attacker will derive the audit keys of all the time periods and the auditing process will become a complete failure. How to safeguard the security of Identity-based cloud auditing if both the update key and the audit key are exposed, is still an open problem. Finding a solution for this problem is the primary objective of this work.

1.2 Literature Survey

Research works on key-exposure resilience are reviewed with a focus on the above said objective. In 2007, Ateniese et al. [7] defined a protocol for PDP and also proposed two PDP schemes to ascertain the possession of data in far-off servers. These schemes used homomorphic verifiable tags and the technique of random sampling. Following the scheme in [7], many PDP schemes [4 – 26] have evolved over time. But the key-exposure issue was first analysed only in 2015 by Yu et al. [8].

The PKI-based PDP schemes in [8-13] audit the data stored in a single cloud and are resilient to the exposure of the audit key. The scheme in [8] provides only forward security and so can prevent the forgery of authenticators of only past time periods. In this scheme, the client must update the key in every time period. To relieve the client from the burden of key updation, the scheme in [9] outsourced the updation of the encrypted version of the audit key to the TPA (Third Party Auditor). The scheme of [10] is both forward and backward secure. The update operation is jointly executed by both the TPA and the client. The update is done using the secret keys of both the TPA and the client. The scheme does not consider the exposure of the secret key of the TPA. The scheme in [11] handles this exposure by providing intrusion resilience. Here, the secret keys of both the TPA and the client also change in every time period. The adversary will not be able to obtain the audit key even if the secret keys of both the client and the TPA of different refreshing periods are exposed. The intrusion resilient scheme of [12] has the cloud server update the authenticators of data blocks using the key computed from the latest audit key. The forward secure scheme of [13] considers the leakage of partial information about the audit key. All these PKI-based schemes have computational and communication overhead of certificate usage [20]. Furthermore, the TPA faces the problem of key-management in the case of multiple clients.

Identity-based cloud auditing schemes of [4, 14-23] skip the need for certificates. In these schemes, the audit key for the initial time period is computed by a trusted third party, the Private Key Generator (PKG) using the identity of the client. The can be the client’s email address, phone number etc. The Identity-based key-exposure resilient schemes of [14,15] are limited only to single cloud storage. The lattice-based scheme of [14] is only forward secure. The scheme of [15] provides both forward and backward security of the audit key. It also supports batch verification of multiple clients’ data which is called batch auditing. It guards the privacy of data from the TPA. It is safe from semi-trusted cloud servers. A malicious cloud server can intentionally delete or modify the cloud data and can go unnoticed. Without retaining the original data blocks, the malicious cloud can generate valid proofs even without the audit key and can pass the audit. This limitation is a side-effect of the privacy preserving feature. Moreover, as already mentioned, it does not consider the exposure of the update key.

The first Identity-based multicloud auditing scheme proposed by Wang [4] in 2015, preserves data privacy against the TPA but is not secure against malicious CSPs. Like in [15], the cloud can generate the audit response without the actual data blocks [16,17]. This security flaw is fixed in [17]. The Identity-based multicloud schemes of [16-19] facilitate batch auditing.

From the analysis of PDP schemes with key-exposure resilience, it is observed that, PKI- based schemes incur certificate related overhead and still have the key-management problem. Some of the Identity-based PDP schemes are not secure against malicious CSPs. The exposure of the update key in Identity-based cloud auditing is still an open problem. Furthermore, multicloud auditing schemes have not regarded the key-exposure problem so far. These are some of the issues in the aspect of key-exposure open for further research.

1.3 Contribution

Based on the issues identified, in this research, an Identity-based PDP scheme with parallel key-insulation is proposed for auditing the data distributed to multiple clouds. The main features of the proposal are:

1. The system model of [15] is extended to support auditing of multiple cloud storage. A CSP interfacing between the TPA and the cloud servers must be a trusted entity. So, the cloud client/TPA in our scheme will interact directly with the cloud servers.

2. The proposed scheme extends the scheme of [15] to support parallel key-insulation [27]. With this feature, there is more than one key updating server (called the Key Updater) and one update key per Key Updater. In each time period, one of the update keys is used to update the audit key. The same update key will not be used in all the time periods. If only the audit key of a time period is exposed, then like the scheme in [15], our proposed scheme is both forward and backward secure. If one of the Key Updaters is compromised and the audit key of a time period is exposed to the adversary, then unlike in [15], the adversary cannot derive the audit keys of all the time periods. He can compute the audit key of only one time period.

3. The scheme protects the privacy of data using the hardness assumption of discrete logarithm problem in cyclic groups. So, during audit, the TPA will not be able to fetch any information about the data from the response messages received from the clouds. It is also secure against malicious CSPs. The scheme in [15] is secure only against semi-trusted CSPs.

4. The scheme can be extended to handle batch auditing and can audit the data blocks of multiple clients simultaneously.

The remaining part of the paper is systematized as follows. The System Model, the notations, the Security Model and the Preliminaries of the proposed scheme are presented in Section 2. Section 3 gives the detailed algorithmic explanation of the proposed scheme followed by detailed security and performance analysis in Sections 4 and 5 respectively. Section 6 concludes highlighting the contributions and the future work.

2. Models and Notations

2.1. System Model

The System Model of [15] is extended to support parallel key-insulation and to audit the data distributed in multiple clouds. Fig. 1 portrays our System Model. In this model, a firm is assumed to store business related data in various clouds. The lifetime of all data files in our system is divided into 0, 1, 2, 3, ... time periods. Like the scheme in [21], the system entity, PKG, is assumed to be from within the firm.

Fig. 1. The System Model

The role of each system entity is as follows:

• Cloud Servers are the cloud storage servers CS₁ , CS₂ , . . ., CS_J . There are many CSPs and each storage server is assumed to be from a distinct cloud.

• Cloud Clients are the staff of the firm, authorized to utilize the cloud storage service for storing official data. A file F of a client is divided into data blocks of fixed size. In a time period t, the cloud client can generate the authentication tags for the data blocks. The data blocks and the corresponding tags are then distributed to the different clouds as per the information in the metadata. The metadata is a data storage dictionary. It contains one record per data block, giving the details of the cloud server where the data block is stored. It is prepared by the client and is shared with the TPA. The number of data blocks of a file can grow over time and the metadata can also be updated.

• Private Key Generator (PKG) is a server in the IT department of the firm and is considered to be a trusted party. It generates the secret keys called the update keys and the public keys for the Key Updaters. There is one update key per Key Updater. It generates the audit key for a cloud client only for the initial time period i.e., the zeroth time period.

• Key Updaters are the servers in the IT department and are presumed to be trusted. These servers are independent of each other. Each client has two secret keys, the time key and the audit key. A Key Updater computes the time key in time period t ≥ 1 using the update key received from the PKG. The time key is then used by the client to update the audit key. The Key Updaters take turns in a round robin fashion to compute the time key of a client. In the above system model, there are three Key Updaters. In general, there can be any number of Key Updaters.

• TPA audits the data stored in multiple clouds. This entity is designed to handle auditing of single client’s data as well as batch auditing. It possess the storage metadata and must be trusted. During audit, the TPA uses the metadata to generate the challenge message for every cloud server. Each of these cloud servers reply back with a response message and the TPA verifies them all. After the audit, the TPA generates the audit report and sends it to the cloud client.

2.2. Notations

The notations used in the proposed scheme are presented in Table 1.

Table 1. Description of Notations

2.3. Brief description of the algorithms and the Security Model

The algorithms of the Identity-based multicloud auditing protocol with parallel-key insulation are briefed as follows:

• SysSetup (1⁷) → (params , 𝛼 , β₀ , β₁ , β₂) : The PKG runs this algorithm. The algorithm takes the security parameter γ and generates the system parameters – params , 𝛼 , β₀ , β₁ , and β_2. params is a set of public parameters. 𝛼 is the master secret key. β₀ , β₁ , β₂ are the secret keys of the Key Updaters KU₀ , KU₁ and KU₂ respectively. These secret keys are also called the update keys. \(P K\) is the system public key. Similarly, \(P K_{0}\), \(P K_{1}\) and \(P K_{2}\) are the public keys of KU0 , KU1 and KU2 respectively. These public keys are included in params.

• InitialAuditKeyGen (\(\text { params, } \alpha, \beta_{0}, \beta_{1}, \beta_{2}, I D\)) → (\(D_{0}\)) : The PKG runs this algorithm. The algorithm creates the audit key \(D_{0}\) of a client using \(I D\), params , 𝛼 , β₀ , β₁ and β₂. \(D_{0}\) represents the audit key of time period t = 0.

• TimeKeyGen (params , β_w , ID , t) → (𝑅_𝑡 ) : The Key Updater KU_w (KU₀ or KU₁ or KU₂ ) runs this algorithm at the start of every time period t ≥ 1, to generate the time key 𝑅_𝑡 of a client. And it is created using the corresponding update key β_w. The inputs ID and t for this algorithm are received from the client. For a particular time period t , only one KU_w runs this algorithm.

• AuditKeyUpdate (𝑅_𝑡 , 𝐷_𝑡−1) → (𝐷_𝑡) : The client runs this algorithm. The algorithm calculates the audit key 𝐷_𝑡 for the period t (t ≥ 1) , using the audit key 𝐷_𝑡−1. The time key of the current time period, 𝑅_𝑡 , is an input to this algorithm.

• AuthGen (params, {𝐹_𝑘 }, r, ID, t, 𝐷_𝑡) → (𝜎) : It can be run by the client in any period t. This algorithm creates the set of authentication tags 𝜎 for the data blocks {𝐹_𝑘} of file F using the audit key 𝐷_𝑡. Here, 𝐹_𝑘 represents the k^th data block of F. The algorithm divides all the data blocks into same number of equal-sized sectors. r is a set of random numbers shared by the sectors of all the data blocks. For each data block, the client adds a record to the metadata table MT. The record contains the cloud server 𝐶S^_𝑗 where the data block will be uploaded.

• ChallengeGen (MT) → (\(\left\{\text { chal }_{j}\right\}\)) : The TPA runs this algorithm to generate the audit challenge messages for multiple clouds. The algorithm first generates a single message called chal. chal consists of random selection of indices of data blocks of a client signed in a particular time period t and an element B ϵ 𝐺₂ . This element B is used to provide data privacy as well as to protect the cloud data from malicious CSPs. Using the metadata table MT, chal is partitioned into a set of challenge messages \(\left\{\text { chal }_{j}\right\}\). A chal_j consists of the data block indices of a client stored in the same cloud server 𝐶S_𝑗 and B.

• ProofGen (params , chal_j , {F_k}, {𝜎_𝑘}, S) → (𝑃_𝑗) : This algorithm is run by the cloud servers in \(\left\{C S_{j}\right\}\) who receive the challenge message chal_j from the TPA. For the challenge chal_j , this algorithm generates the audit response P_j from the set of data blocks {𝐹_𝑘} and the set of authenticators {𝜎_𝑘} (of a client) stored in \(C S_{j}\).

• ProofVerify (params , \(\left\{\text { chal }_{j}\right\}\), \(\left\{P_{j}\right\}\)) → (0/1) : The algorithm verifies the cloud data of a client and is run by the TPA. The algorithm aggregates the responses {𝑃_𝑗 } received from all the challenged clouds in \(\left\{C S_{j}\right\}\). It then verifies the aggregated response for a particular time period t (which is given in the challenge message) using the system public key PK. and the public keys of the Key Updaters PK₀, PK₁ and PK₂. It returns 1, if all the challenged data blocks are secure in the multicloud storage.

BatchAuditProofGen and BatchAuditProofVerify are the algorithms for batch auditing.

• BatchAuditProofGen (params , chal_j, {𝐹ik}, {𝜎_ik}, {𝑆_t}) → (𝑃_𝑗) : This algorithm is run by all the challenged clouds in \(\left\{C S_{j}\right\}\). Unlike ProofGen, here {𝐹_𝑖k} and {σ_ik} refer to the set of data blocks and the set of authenticators of several clients (subscript i refers to the i^th client), stored in 𝐶S_𝑗. 𝑆_𝑖 is unique for every file. And the audit challenge chal_j consists of the indexes of data blocks of many cloud clients. The time period of the authentication tags of the data blocks of a client can be different from the other client. The algorithm generates the audit proof 𝑃_𝑗 for the data blocks of cloud clients in chal_j.

• BatchAuditProofVerify (params, {chal_j}, {𝑃_𝑗}) → (0/1) : This algorithm is similar to the ProofVerify algorithm. It is run by the TPA to verify the integrity of the data blocks of multiple clients. Unlike ProofVerify, the audit challenge message 𝑐𝑐ℎ𝑎𝑎𝑎𝑎𝑗𝑗 and the audit proof message 𝑃_𝑗 involve the data blocks of multiple cloud clients.

Definition: An auditing protocol for multicloud storage is said to be resilient to the exposure of both the audit key and the update key, if for any adversary A (malicious CS), the probability with which A wins the Proof-Forge game on a set of data blocks of a file is negligible.

The Proof-Forge game is played by the adversary A and the challenger C. In this game, there are four phases, the Setup phase, the Query phase, the Challenge phase and the Forgery phase.

Setup phase: The challenger C sets up the public parameters params and the public keys 𝑃K₀ ,𝑃K₁ and 𝑃K₂ . These public parameters and the public keys are given to A. Let’s assume that the update keys β₁ and β₂ are exposed to the adversary.

Query phase: In this phase, A can query the oracles 𝐻₁ , 𝐻₂ , 𝐻₃ , AuditKey and AuthGen. And C responds. Here, C runs the key update algorithms. In any time period t , A can get the audit key but must not ask the time key. A can compute the time key of certain time periods using the exposed keys β₁ and β₂ . In any time period t , A can query the authenticator of data blocks {𝐹_𝑘} and C must compute and return the authenticators in this time period. As a time period ends, A can decide to either remain in this phase or go to the challenge phase.

Challenge phase: Here, C selects an identity ID^_∗, a time period 𝑡^∗ and some data block indices 𝑏_1* , 𝑏_2∗ , …., 𝑏_𝑐∗ and includes them in a challenge 𝑐ℎ𝑎l^∗. C demands A to provide a valid proof of possession P^* for chal^* such that

1. (ID^_∗ , 𝑡^∗), (ID^_∗ , 𝑡^∗+1) and (ID^_∗ , 𝑡^∗+2) were not used previously by A to query the AuditKey oracle.

2. t^* is the time period which requires β₀ to compute the time key 𝑅_𝑡∗ .

3. None of the b_k^* of chal^* was used by A to query the TagGen oracle in time period 𝑡^∗.

Adversary A would have obtained the audit keys which are earlier to 𝑡^∗ and/or which are later to 𝑡^∗+2 in the query phase (here, 2 in 𝑡^∗+ 2 is also no_of_update_keys - 1). A would also have computed the time keys of 𝑡^∗- 2 , 𝑡^∗- 1 ,𝑡𝑡∗+ 1 and 𝑡^∗+ 2 using the exposed keys β₁ and β₂ . Even then, it is practically not easy for A to calculate the audit key of 𝑡^∗ without the time key 𝑅_𝑡^∗ of 𝑡^∗. Computation of 𝑅_𝑡^∗ requires the update key β₀ which is not known to A.

Forgery phase: Here, A responds with a proof 𝑃^∗ for chal^∗. A is said to win the game only if ProofVerify (chal^∗, 𝑃^∗, PK, PK₀, PK₁, PK₂) = 1.

2.4. Preliminaries

The proposed scheme uses pairing-based cryptographic algorithms to implement auditing. This section presents the bilinear map used by these algorithms and the computational problem used in security analysis.

• Bilinear Map

Consider G₁ and G₂ to be two multiplicative cyclic groups of large prime order q. The map e : G₁  × G₁  → G₂ is a bilinear map [28] if all these axioms are satisfied:

- Bilinearity: For all u, v ϵ G₁ and x, y ϵ \(Z_{q}^{*}\), \(e\left(u^{x}, v^{y}\right)=e(u, v)^{x y}\)

- Non-degeneracy: There exists \(g, h \in G_{1}\) such that \(e(g, h)=1\)

- Computability: For all u, v ϵ G₁ , we can compute \(e(u, v) \in G_{2}\) in polynomial time.

• CDH problem

Given (g, g^a, g^b) , where g is a generator of multiplicative group G₁ of prime order q and a, b ϵ \(Z_{q}^{*}\), the Computational Diffie-Hellman (CDH) problem [28] is to compute g^ab. It is assumed that the CDH problem in G₁ is hard i.e., there is no efficient algorithm to solve the problem with non-negligible probability.

3. Detailed Description of our Proposed Scheme

An Identity-based scheme with parallel key-insulation is proposed for multicloud auditing. It uses the System Model and the bilinear map concept of section 2. It extends the key updation technique of the general signature scheme in [29] to support three update keys. It also supports blockless verification. A data file of a client has many data blocks distributed in cloud servers of different CSPs. Each block is divided into a fixed number of equal-sized sectors.

The lifetime of the audit key 𝐷_𝑡 of a client is partitioned into time periods 0, 1, 2, 3, 4, . . .. and the value of the key changes in each period. 0 is the initial time period (i.e., the time period t = 0 initially). 1 is the next time period. 2 comes after 1. 3 comes after 2. Likewise, the time period t increments by 1. The audit key is updated at the beginning of each period. In any period, new data blocks of the file F are signed using the audit key of the corresponding period and then stored in the cloud servers. It is the client who decides which block is to be stored in which server (metadata). Similarly, in any period, a block stored in any cloud server can be modified and re-signed using the audit key of the corresponding period. The client, if he intends can also re-sign all the stored data blocks using the latest audit key without any modification. Unlike the audit key, the public keys used for integrity verification will not change in any period.

Unlike in [15], there are three Key Updaters KU₀ , KU₁ and KU₂ . Each of the Key Updaters obtain an update key from the PKG. β₀, β₁ and β₂ are the update keys of KU₀ , KU₁ and KU₂ respectively. These update keys are independent of each other. At t = 0, the audit key D₀ is generated by the PKG using the master secret key α and all the update keys β₀, β₁ and β₂ (Fig. 2). In every t ≥ 1, the audit key 𝐷_𝑡−1 gets updated to 𝐷_𝑡 using the time key 𝑅_𝑡 . After the updation, both 𝐷_𝑡−1 and 𝑅_𝑡 are deleted.

Fig. 2. Generation of initial audit key

The Key Updaters take turns in a round robin fashion to generate the time key 𝑅_𝑡 . The Key Updater KU₁ uses β₁ to create the time key in time periods 1, 4, 7, 10, 13…. KU₂ creates the time key in time periods 2, 5, 8, 11, 14… using β₂ . Similarly, KU₀ generates the time key in time periods 3, 6, 9, 12, 15…… using β₀. In general, in time period t, KU_w computes the time key 𝑅_𝑡 using the update key β_w. Here, w = t mod 3. In all t ≥ 1, the audit key 𝐷_𝑡 is computed using the time key 𝑅_𝑡 of t and the audit key 𝐷_𝑡−1 of t - 1. This is called updation of the audit key. Fig. 3 illustrates the updation of the audit key in time periods 1, 2 and 3. Similarly, Fig. 4 illustrates the updation in time periods 4, 5 and 6.

Fig. 3. Updation of the audit key in time periods 1, 2 and 3

Fig. 4. Updation of the audit key in time periods 4, 5 and 6

As per our proposal, if an update key and an audit key of a period are both exposed to the adversary, then he can compute the audit key of only one time period. For example, if both β₀ and 𝐷_𝑡−1 are exposed, then the adversary can compute 𝐷_𝑡 . Similarly, if both β₀ and 𝐷_𝑡 are exposed, then the adversary can derive 𝐷_𝑡−1. But he cannot obtain the audit keys of the remaining time periods.

During audit, the TPA prepares a challenge message consisting of random data block indices, splits the challenge message into a set of smaller challenge messages using the metadata and distributes them to the corresponding clouds. Here, the TPA can challenge all the clouds or some of the clouds (where the challenged blocks are present). The responses from the challenged clouds are then aggregated and verified. To provide security against malicious cloud service providers, B must be different in each audit, i.e., the element \(\rho \in Z_{q}^{*}\) used to generate B must differ in each audit.

Each algorithm of the proposed scheme is listed in steps as:

• SysSetup

1. Given a security parameter , select two multiplicative cyclic groups, G₁ and G₂ of prime order \(q>2^{Y}\) and a bilinear map \(e: G_{1} \times G_{1} \rightarrow G_{2}\).

2. Select three generators 𝑔, 𝑢, P ϵ G₁.

3. Randomly choose four elements – α, β₀, β_1, β₂ ϵ \(Z_{q}^{*}\). Let α be the master secret key. Let β₀, β₁ and β₂ be the update keys (secret keys) of the Key Updaters KU₀, KU₁ and KU₂ respectively.

4. Compute the system public key using the master secret key as

\(P K=g^{\alpha}\)       (1)

5. PK₀ , PK₁ and PK₂ are the public keys of the Key Updaters KU₀, KU₁ and KU₂ respectively. Compute

\(P K_{0}=g^{\beta_{0}}\)       (2)

\(P K_{1}=g^{\beta_{1}}\)       (3)

\(P K_{2}=g^{\beta_{2}}\)       (4)

6. Select three cryptographic hash functions 𝐻₁, 𝐻₂: {0, 1}^* → 𝐺₁ and\(H_{3}:\{0,1\}^{*} \times G_{1} \rightarrow Z_{q}^{*}\).

7. Choose the pseudo-random function \(f: Z_{q}^{*} \times\{1,2,3, \ldots, n\} \rightarrow Z_{q}^{*}\).

8. Include the public parameters in params as params = (G₁ , G₂ , e , 𝑔 , u , P, PK , PK₀ , PK₁ , PK₂ , 𝐻₁ , 𝐻₂ , 𝐻₃ , f ) and publish them. Send β₀ , β₁ and β₂ secretly to the respective Key Updaters.

• InitialAuditKeyGen

1. Input the identity \(I D \in\{0,1\}^{*}\) of a client. Compute the audit key \(D_{0} \in G_{1}\) for the initial time period t=0 using the secret keys α , β₀, β₁ and β₂ as,

\(D_{0}=H_{1}(I D)^{\alpha} H_{2}(I D \|-2)^{\beta_{1}} H_{2}(I D \|-1)^{\beta_{2}} H_{2}(I D \| 0)^{\beta_{0}}\)       (5)

2. Send D₀ to the client over a protected channel.

The client receives the audit key and checks its validity using the equation

\(\begin{gathered} e\left(g, D_{0}\right)=e\left(P K, H_{1}(I D)\right) e\left(P K_{1}, H_{2}(I D \|-2)\right) e\left(P K_{2}, H_{2}(I D \|-1)\right) \\ e\left(P K_{0}, H_{2}(I D \| 0)\right) \end{gathered}\)       (6)

• TimeKeyGen

1. Compute the time key \(R_{t} \in G_{1}\) for the client for the time period t using the secret β_w as,

\(R_{t}=\left(H_{2}(I D \| t)\left(H_{2}(I D \| t-3)\right)^{-1}\right)^{\beta_{w}}\)       (7)

Here, t is the current period and (t – 3) is the time period when the time key was last updated by the same Key Updater KU_w. β_w is the update key of Key Updater KU_w and w = t mod 3. Depending on the value of t, one of β₀ , β₁, β₂ is used in (7).

2. Send 𝑅_𝑡 to the client over a protected channel.

• AuditKeyUpdate

1. Validate the time key received from the Key Updater as

\(e\left(g, R_{t}\right)=e\left(P K_{W}, H_{2}(I D \| t)\left(H_{2}(I D \| t-3)\right)^{-1}\right)\)        (8)

Here, PK_W is the public key of the Key Updater KU_W which was used to generate R_t.

2. Update the audit key using,

\(D_{t}=R_{t} D_{t-1}\)       (9)

3. Delete the keys R_t and D_t-1.

• AuthGen

Randomly select \(x \in Z_{q}^{*}\) and compute 𝑆 = 𝑔^𝑥. Let 𝐹_𝑘 be the k^th data block of the file F of the cloud client, predetermined to be stored in cloud server CS_j. Here, k is the data block index. Partition each data block 𝐹_𝑘 into s number of sectors, 𝐹_𝑘= {𝐹_𝑘1 , 𝐹_d , ...., 𝐹_ks}. For each sector l of a data block, there is a random number 𝑟_𝑙 and the set \(r=\left\{r_{l} \mid r_{l} \in Z_{q}^{*}, l=1,2,3, \ldots, s\right\}\) is common to all the data blocks. For each data block F_k ,

1. Compute the hash value, \(h_{k}=H_{3}\left(I D_{i} \| \text { name }\left\|C S_{j}\right\| k \| t, S\right)\) where name is the name of the file.

2. Compute \(M_{k}=\sum_{l=1}^{S} r_{l} F_{k l} \in Z_{q}^{*}\)       (10)

3. Compute \(T_{k}=P^{h_{k} x} u^{M_{k}} D_{t}\)       (11)

Here, 𝐷_𝑡 is the audit key of the current time period t . The authentication tag of data block 𝐹_𝑘 is 𝜎_𝑘 = {𝑇_𝑘 ,𝑡}. Add the record 𝛷_𝑘 = (name, k, CS_j, t) to the metadata table MT. The set of authentication tags of F is \(\sigma=\left\{S,\left\{\sigma_{k}\right\}\right\} .\) S is the same for all the data blocks of F .

The client uploads the block/tag pairs to the respective cloud servers and sends the metadata table MT to the TPA. The TPA uses the metadata table to generate the audit challenge.

• ChallengeGen

1. Select c number of data block indexes of a data file of a client randomly. These data blocks must have been signed in a particular time period t.

2. Select an element ρ, randomly from \(Z_{q}^{*}\) and compute 𝐵 𝜖 𝐺₂ as,

\(B=e\left(u, g^{\rho}\right)\)       (12)

3. Generate the challenge message, \(\text { chal }=(I, t, A, B)\) where \(I=I_{1} \cup I_{2} \ldots \cup I_{j} \ldots \cup I_{j}\). Here, I_j is the index set for cloud server and Here, 𝐼_𝑗 is the index set for cloud server CS_j and 𝐼_𝑗 = {𝑏₁, 𝑏₂, 𝑏₃, . . .} where 𝑏₁, 𝑏₂, 𝑏₃, … are the indexes of data blocks stored in CS_j. \(A=\left\{a_{j} \mid j \in C \text { and } a_{j} \in Z_{q}^{*}\right\}\) where C is the set of challenged clouds in {CS_j} and 𝑎_𝑗 is the key for CS_j. 𝑎_𝑗 will be used by CS_j as an input to pseudo-random function in ProofGen.

4. Split the challenge message chal into multiple challenge tokens chal_j = (I_j,t, a_j, 𝐵). There is one chal_𝑗 per cloud server CS_𝑗 .

5. Send each challenge message chal_j to the respective CS_j .

• ProofGen

1. On receiving the challenge message chal_j , compute the coefficient \(v_{k} \in Z_{q}^{*}\) for each block index k in 𝐼_𝑗 of chal_j using the pseudo-random function as

\(v_{k}=f_{a_{j}}(k)\)       (13)

2. Compute \(\breve{\mathrm{T}}_{j} \in G_{1}\) using the authenticators T_k of blocks indexed in chal_j and its corresponding coefficients \(v_{k}\) computed in step 1 as

\(\breve{\mathrm{T}}_{j}=\prod_{k \in I_{j}}\left(T_{k}\right)^{v_{k}}\)       (14)

3. For each sector l of the data blocks, compute \(f=\sum_{k \in I_{j}} v_{k} F_{k l} \in Z_{q}^{*}\) and set

\(B_{l}=B^{f}\)       (15)

4. Send the proof \(P_{j}=\left\{S, \check{T}_{j},\left\{B_{l}\right\}_{l=1,2,3, \ldots, s}, t\right\}\) to the TPA. Here, s is the number of sectors.

• ProofVerify

1. After receiving the audit proof messagess {𝑃_𝑗} from all the challenged cloud servers, compute \(\check{\mathrm{T}}=\prod_{j \in C} \check{\mathrm{T}}_{j}\)       (16)

Here C is the set of challenged cloud servers in {CS_j}.

2. Compute \(N=\prod_{j \in C} \prod_{l=1}^{s} B_{l}^{r_{l}}\)       (17)

3. Verify the integrity of the data stored in multiple clouds using the equation,

\(\begin{aligned} \left(g^{\rho}, \check{\mathrm{T}}\right)=&\left(S^{\rho}, P^{\sum_{k \in I}\left(h_{k} v_{k}\right)}\right) e\left(P K^{\rho}, H_{1}(I D)^{\sum}{\Sigma}_{k \epsilon I} v_{k}\right) \\ & e\left(P K_{w^{\prime \prime \prime}}^{\rho}, H_{2}(I D \| t-2)^{\sum_{k \in I} v_{k}}\right) \\ & e\left(P K_{w^{\prime \prime}}^{\rho}, H_{2}(I D \| t-1)^{\sum_{k \in I} v_{k}}\right) \\ & e\left(P K_{w^{\prime}}^{\rho}, H_{2}(I D \| t)^{\sum_{k \in I} v_{k}}\right) N \end{aligned}\)       (18)

Here, \(h_{k}=H_{3}\left(I D_{i} \| \text { name }\left\|C S_{j}\right\| k \| t, S\right),\) \(I=I_{1} \cup I_{2} \ldots \cup I_{j} \ldots \cup I_{J}\), \(w^{\prime}=t \bmod 3, w^{\prime \prime}=(t-1) \bmod 3 \text { and } w^{\prime \prime \prime}=(t-2) \bmod 3\). If any of 𝑤′ or 𝑤′′ or 𝑤′′′ is negative, then the constant 3 is added to it.

4. Return 1 if L.H.S. = R.H.S. in (18), otherwise return 0.

Proof of Correctness for (18):

\(e\left(g^{\rho}, \check{\mathrm{T}}\right)=e\left(g^{\rho}, \prod_{j \in C} \check{\mathrm{T}}_{j}\right)\)       (19)

substituting (14) in (19)

\(e\left(g^{\rho}, \breve{\mathrm{T}}\right)=e\left(g^{\rho}, \prod_{j \in C} \prod_{k \in I_{j}}\left(T_{k}\right)^{v}{ }^{v}\right)\)       (20)

substituting (11) in (20)

\(\begin{aligned} e\left(g^{\rho}, \breve{\mathrm{T}}\right) &=e\left(g^{\rho}, \prod_{j \in C} \prod_{k \in I_{j}}\left(P^{h_{k} x} u^{M_{k}} D_{t}\right)^{v_{k}}\right) \\ &=e\left(g^{\rho}, \prod_{k \in I}\left(P^{h_{k} x}\right)^{v_{k}}\right) e\left(g^{\rho}, \prod_{k \in I}\left(u^{M_{k}}\right)^{v_{k}}\right) e\left(g^{\rho}, \prod_{k \in I}\left(D_{t}\right)^{v_{k}}\right) \end{aligned}\)       (21)

substituting (9) in (21)\(\begin{aligned} e\left(g^{\rho}, \breve{\mathrm{T}}\right)=& e\left(\left(g^{x}\right)^{\rho}, \prod_{k \in I} P^{h_{k} v_{k}}\right) e\left(g^{\rho}, u^{\sum_{k \in I}\left(M_{k} v_{k}\right)}\right) e\left(g^{\rho}, \prod_{k \in I}\left(R_{t} D_{t-1}\right)^{v_{k}}\right) \\ &=e\left(S^{\rho}, P^{\sum_{k \in I}\left(h_{k} v_{k}\right)}\right) B^{\sum_{k \in I}\left(M_{k} v_{k}\right)} \end{aligned}\)

 \(e\left(g^{\rho}, \prod_{k \in I}\left(H_{2}(I D \| t)^{\beta_{w}^{\prime}}\left(H_{2}(I D \| t-3)^{\beta_{w}^{\prime}}\right)^{-1} R_{t-1} D_{t-2}\right)^{v_{k}}\right)\)

\(\begin{aligned} e\left(g^{\rho}, \check{\mathrm{T}}\right)=& e\left(S^{\rho}, p^{\Sigma_{k \in I}\left(h_{k} v_{k}\right)}\right) N e\left(\left(g^{\alpha}\right)^{\rho}, \prod_{k \in I} H_{1}(I D)^{v_{k}}\right) \\ & e\left(\left(g^{\beta_{w}^{\prime \prime \prime}}\right)^{\rho}, \prod_{k \in I} H_{2}(I D \| t-2)^{v_{k}}\right) \\ & e\left(\left(g^{\beta_{w}^{\prime \prime}}\right)^{\rho}, \prod_{k \in I} H_{2}(I D \| t-1)^{v_{k}}\right) \\ & e\left(\left(g^{\beta_{w}^{\prime}}\right)^{\rho}, \prod_{k \in I} H_{2}(I D \| t)^{v_{k}}\right) \end{aligned}\)

\(\begin{aligned} e\left(g^{\rho}, \mathrm{T}\right)=& e\left(S^{\rho}, P^{\sum_{k \in I}\left(h_{k} v_{k}\right)}\right) e\left(P K^{\rho}, H_{1}(I D)^{\sum_{k \in I} v_{k}}\right) \\ e &\left(P K_{w^{\prime \prime \prime}}^{\rho}, H_{2}(I D \| t-2)^{\sum_{k \in I} v_{k}}\right) e\left(P K_{w^{\prime \prime}}^{\rho}, H_{2}(I D \| t-1)^{\sum_{k \in I} v_{k}}\right) \\ & e\left(P K_{w^{\prime}}^{\rho}, H_{2}(I D \| t)^{\sum_{k \in I} v_{k}}\right) N \end{aligned}\)

Here, \(w^{\prime}=t \bmod 3, w^{\prime \prime}=(t-1) \bmod 3 \text { and } w^{\prime \prime \prime}=(t-2) \bmod 3\)

For the purpose of batch auditing, the challenge is altered to include the block indices of multiple cloud clients - chal_𝑗 = (𝐼_𝑗, 𝑎_𝑗, 𝐵). Here, 𝐼_𝑗 = {(𝑖,𝑡, 𝑏₁, 𝑏₂, 𝑏₃, . . . )}. The time period of the data blocks of a client indexed in chal_𝑗 may be different from other clients.

• BatchAuditProofGen

1. After receiving the challenge message chal_𝑗, generate the coefficient for each index k in the challenge chal_𝑗 using (13) .

2. Compute \(\breve{\mathrm{T}}_{j}=\prod_{i, k \in I_{j}}\left(T_{i k}\right)^{v_{k}} \in G_{1}\)       (22)

3. For each sector l of client i, compute

\(f=\sum_{i, k \in I_{j}} v_{k} F_{i k l} \in Z_{q}^{*}\)       (23)

\(B_{i l}=B^{f}\)       (24)

Totally there will be number_of_clients × 𝑠 values of \(B_{i l}\) where s is the number of sectors.

4. Send the proof \(P_{j}=\left\{\left\{S_{i}\right\}_{i \in I_{j}}, \breve{\mathrm{T}}_{j},\left\{B_{i l}\right\}_{i \in I_{j}, l=1,2,3, \ldots,},\{t\}_{i \in I_{j}}\right\}\) to the TPA.

• BatchAuditProofVerify

1. Compute \(\breve{\mathrm{T}}=\prod_{j \in C} \breve{\mathrm{T}}_{j}\)       (25)

2. Compute 𝑁_𝑖 value for each client i whose data blocks are involved in the challenge as \(N_{i}=\prod_{j \in C} \prod_{l=1}^{s} B_{i l}{ }^{r_{l}}\)       (26)

3. Verify the data of multiple clients stored in multiple clouds using the equation,   \(\begin{aligned} \left(g^{\rho}, \breve{\mathrm{T}}\right)=\prod_{i \in O} e\left(S_{i}^{\rho}, P \sum_{k \in I}\left({ }^{h}{ }_{k} v_{k}\right)\right) e\left(P K^{\rho}, \prod_{i \in O} H_{1}\left(I D_{i}\right)^{\sum k \in I} v_{k}\right) & e\left(P K_{0}^{\rho}, \prod_{i \in O} H_{2}\left(I D_{i} \| t_{a}\right)^{\sum_{k \in I}{ }^{v}{ }_{k}}\right) \\ & e\left(P K_{1}^{\rho}, \prod_{i \in O} H_{2}\left(I D_{i} \| t_{b}\right)^{\sum_{k \in I} v_{k}}\right) \\ & e\left(P K_{2}^{\rho}, \prod_{i \in O} H_{2}\left(I D_{i} \| t_{c}\right)^{\sum_{k \in I} v_{k}}\right) \prod_{i \in O} N_{i} \end{aligned}\)

(27)

Here, \(h_{k}=H_{3}\left(I D_{i} \| \text { name }\left\|C S_{j}\right\| k \| t, S_{i}\right)\), one of 𝑡_𝑎 , 𝑡_𝑏 , 𝑡_𝑐 is time period t which is given in the challenge and the remaining are time periods t - 1 and t - 2. The notations 𝑡_𝑎 , 𝑡_𝑏 , 𝑡_𝑐 are used in the above equation since the time period of data blocks may differ for different clients. Here, I is the union of data block indices of multiple cloud servers and 𝐼 = 𝐼₁ ⋃ 𝐼₂ . . . ⋃ 𝐼_𝑗 … ⋃ 𝐼_𝐽 where 𝐼𝑗 is the set of data block indices of cloud server {CS_j}. O is the set of cloud clients i.e., 𝑂 = {𝑖} whose data is to be verified in batch auditing.

4. Return 1 if L.H.S. = R.H.S. in (27), otherwise return 0.

4. Security Analysis

Theorem 1 (Resilience to key-exposure): If the CDH problem in 𝐺₁ is hard, then the proposed multicloud auditing scheme is resilient to the exposure of both the audit key and the update key.

Proof: The CDH problem is to find g^ab , given {𝑔, 𝑔^𝑎, 𝑔^𝑏} where 𝑔 is a generator of multiplicative group 𝐺₁ of order q and \(a, b \in Z_{q}^{*}\). Let A be an adversary and L be a challenger. The goal of L is to solve the CDH problem. Algorithm C simulates the challenger. A ProofForge game is used between A and C. If A can produce a valid proof with non-negligible probability, then A is said to have won the game and therefore C can solve the CDH problem.

• SysSetup phase: Consider 𝐺₁ and 𝐺₂ to be multiplicative cyclic groups of order q. C sets the system public key, PK = 𝑔^𝛼 ϵ 𝐺¹ and the public keys of the Key Updaters, PK₀ = 𝑔^𝑎 , PK₁ = 𝑔^𝛽₁ and PK₂ = 𝑔^𝛽2 . C picks m and n randomly from \(Z_{q}^{*}\) , computes 𝑢&bsp;= 𝑔^𝑚 ϵ 𝐺₁ and 𝑃 = 𝑔^𝑛 ϵ 𝐺₁ . C then forwards (𝐺₁ , 𝐺₂ , e , g , u , P, PK , PK₀ , PK₁ , PK₂) to A.

• Query phase: C maintains a 𝐻₁ list, a 𝐻₂ list, a 𝐻₃ list, an AuditKey list and a Tag list which are initially empty. Adversary A can query the 𝐻₁ Oracle, the 𝐻₂ Oracle, the 𝐻₃ Oracle, the AuditKey Oracle or the AuthGen Oracle at any time. Consider that A makes ‘X ’ AuditKey queries and ‘Y ’ AuthGen queries. Let i denote a client. For an AuditKey query or an AuthGen query on identity ID_𝑖 of a client i, let us assume that a 𝐻₁ query and three 𝐻₂ queries (for t , t - 1 and t - 2) were already been made on that identity.

- 𝐻₁ Oracle Query: When A asks for 𝐻₁ output with identity input ID_𝑖 , C looks for an entry for ID_𝑖 in the 𝐻₁ list and finds the tuple (ID_𝑖 , 𝑥_𝑖 , 𝑔^𝑥_𝑖 ) and returns 𝑔^𝑥_𝑖. If ID_𝑖 is not in the list, then C picks 𝑥_𝑖 𝜖 \(Z_{q}^{*}\) at random,sets 𝐻₁(ID_𝑖) = 𝑔^𝑥_𝑖 , adds the tuple (ID_𝑖 , 𝑥_𝑖 , 𝑔^𝑥_𝑖 ) to the 𝐻₁ list and returns 𝑔^𝑥_𝑖.

- 𝐻₂ Oracle Query: The adversary A queries the 𝐻₂ Oracle with input (ID_𝑖 ,𝑡 ). C returns ℎ_2𝑖 𝜖𝜖 𝐺₁ from the 𝐻₂ list, if the given input matches the tuple (ID_𝑖 , 𝑡 , 𝑑_𝑖 , 𝑦_𝑖,𝑡 ,𝑡𝑡 , ℎ_2𝑖) in the list. Otherwise, C flips a coin 𝑑_𝑖 ϵ {0, 1} such that, the probability 𝑃[𝑑_𝑖 = 0] = 𝜆 and the probability 𝑃[𝑑_𝑖 = 1] = 1 − 𝜆.

i. If 𝑑_𝑖 = 0, C randomly selects 𝑦_𝑖,𝑡 ϵ \(Z_{q}^{*}\) and computes

𝐻₂(ID_𝑖 || 𝑡 ) = 𝑔^{𝑦_𝑖,𝑡} = ℎ_2𝑖 

ii. If 𝑑_𝑖 = 1, C randomly selects 𝑦_𝑖,𝑡 ϵ \(Z_{q}^{*}\) and computes

\(H_{2}\left(I D_{i} \| t\right)=\left(g^{b}\right)^{y_{i, t}}=h_{2 i}\)

- 𝐻₃ Oracle Query: For A’s input \(\left(I D_{i}, \text { name }, C S_{j}, k, t, S_{i}\right)\), C returns the value 𝑧_𝑖 from the 𝐻₃ list, if \(\left(I D_{i}, \text { name }, C S_{j}, k, t, S_{i}, z_{i}\right)\) is already in the list. If there is no entry, then C randomly picks z_i from \(Z_{q}^{*}\), returns z_i and adds the tuple \(\left(I D_{i}, \text { name }, C S_{j}, k, t, S_{i}, z_{i}\right)\) to the H₃ list.

- AuditKey Oracle Query: When asked the audit key of (ID_𝑖 ,𝑡 ), C accesses the tuple \(\left(I D_{i}, t, D_{i, t}\right)\) in the AuditKey list and gives 𝐷_𝑖,𝑡 to A. If the tuple is absent, then C finds the tuple \(\left(I D_{i}, t, d_{i}, y_{i, t}, h_{2 i}\right)\) in the 𝐻₂ list. Here,

i. If 𝑑_𝑖 = 0 , C computes the audit key of time period t as \(D_{i, t}=\left(g^{x_{i}}\right)^{\alpha}\left(g^{y_{i, t-2}}\right)^{\beta_{w}^{\prime \prime}}\left(g^{y_{i, t-1}}\right)^{\beta_{w}^{\prime \prime}}\left(g^{y_{, t}}\right)^{\beta_{w}^{\prime}}\). Here, 𝑤′ = 𝑡 mod 3, 𝑤′′ = (𝑡 − 1) 𝑚ot 3 and 𝑤′′′ = (𝑡 − 2) mod 3. C adds \(\left(I D_{i}, t, D_{i, t}\right)\) to the AuditKey list and gives 𝐷_𝑖,𝑡 to A.

ii. If 𝑑_𝑖 = 1, C aborts with an unsuccessful message.

AuthGen Oracle Query: A queries the authentication tag of \(\left(I D_{i}, t, F_{i k}\right)\) and C returns σ_ik if the tuple (ID_𝑖 ,𝑡 , 𝐹_𝑖k , 𝜎_𝑖k) is available in the Tag list. Otherwise, C recovers the tuple (ID_𝑖 , 𝑡 , 𝑑_𝑖 , 𝑦_𝑖,𝑡 , ℎ_2𝑖) from the 𝐻₂ list. Here,

i. If 𝑑_𝑖 = 0, C picks 𝑝_𝑖 from \(Z_{q}^{*}\) and sets 𝑆_𝑖 = 𝑔^𝑝𝑖 . Picks up 𝑧_𝑖 ϵ \(Z_{q}^{*}\) and adds the tuple \(\left(I D_{i}, \text { name }, C S_{j}, k, t, S_{i}, z_{i}\right)\) to the 𝐻₃ list. It then computes

𝑇_𝑖k = (𝑔^𝑛)^𝑧𝑖 𝑝𝑝𝑖𝑖 (𝑔𝑔𝑚𝑚)𝑀𝑀𝑖𝑖𝑖𝑖 (𝑔𝑔𝑥𝑥𝑖𝑖)𝛼𝛼 (𝑔𝑔𝑦𝑦𝑖𝑖,𝑡𝑡−2)𝛽𝛽𝑤𝑤 ′′′ (𝑔𝑔𝑦𝑦𝑖𝑖,𝑡𝑡−1)𝛽𝛽𝑤𝑤 ′′ \(T_{i k}=\left(g^{n}\right)^{z_{i} p_{i}}\left(g^{m}\right)^{M_{i k}} \quad\left(g^{x_{i}}\right)^{\alpha}\left(g^{y_{i, t-2}}\right)^{\beta_{w}^{\prime \prime \prime}}\left(g^{y_{i, t-1}}\right)^{\beta_{w}^{\prime \prime}}\left(g^{y_{i, t}}\right)^{\beta_{w}^{\prime}}\)

where

\(M_{i k}=\sum_{l=1}^{s} r_{l} F_{i k l}, \quad w^{\prime}=t \bmod 3, w^{\prime \prime}=(t-1) \bmod 3\) and

𝑤′′′ = (𝑡 − 2) mod 3. Sets 𝜎_𝑖k = {S_i , T_ik , t} and adds (ID_𝑖 ,𝑡 , 𝐹_𝑖k , 𝜎_𝑖k) to the Tag list. Also returns 𝜎_𝑖k to A.

ii. If 𝑑_𝑖 = 1, C aborts reporting failure.

• Challenge phase: Here, C selects an identity ID_𝑖 and challenges A with \(\text { chal }^{*}=\)\(\left\{b_{1^{*}}, b_{2^{*}}, \ldots, b_{c^{*}}, t^{*}, a_{j}, B\right\}\). Here, \(b_{1^{*}}, b_{2^{*}}, \ldots, b_{c^{*}}\) is the set of indexes I of data blocks stored in 𝐶S_𝑗 . Value \(B=e\left(u, g^{\rho^{*}}\right) \in G_{2}\) where 𝜌∗ is a random element of \(Z_{q}^{*}\).

• Forgery phase: Here, A responds with a valid proof \(P^{*}=\left\{S^{*}, \check{\mathrm{T}}^{*},\left\{B_{l}^{*}\right\}_{l=1,2,3, \ldots, s}, t^{*}\right\}\) with a probability as least ϵ.

- Breaking CDH: Algorithm C accesses the tuple \(\left(I D^{*}, t^{*}, d^{*}, y_{t^{*}}, h_{2^{*}}\right)\) in the 𝐻₂ list and checks the value of 𝑑^∗.

i. If 𝑑^∗ = 0, C aborts.

ii. If 𝑑^∗ = 1, C proceeds as follows:

\(\begin{aligned} e\left(g^{\rho^{*}}, \breve{\mathrm{T}}^{*}\right)=& e\left(\left(S^{*}\right)^{\rho^{*}}, P^{\sum_{k^{*}} \epsilon I}\left(h_{k^{*}} v_{k^{*}}\right)\right) e\left(P K^{\rho^{*}}, H_{1}\left(I D^{*}\right)^{\sum_{k^{*}} \epsilon I}\left(v_{k^{*}}\right)\right) \\ & e\left(P K_{1}^{\rho^{*}}, H_{2}\left(I D^{*} \| t^{*}-2\right)^{\sum_{k^{*} \epsilon I}\left(v_{k^{*}}\right)}\right) \\ & e\left(P K_{2}^{\rho^{*}}, H_{2}\left(I D^{*} \| t^{*}-1\right)^{\sum_{k^{*} \in I}\left(v_{k^{*}}\right)}\right) \\ & e\left(P K_{0}^{\rho^{*}}, H_{2}\left(I D^{*} \| t^{*}\right)^{\sum_{k^{*} \in I}\left(v_{k^{*}}\right)}\right) N^{*} \end{aligned}\)       (28)

\(\text { where } h_{k^{*}}=H_{3}\left(I D^{*} \| \text { name }^{*}\left\|C S_{j}\right\| k^{*} \| t^{*}, S^{*}\right)\)

substituting the following in (28),

\(P \text { by } g^{n}, h_{k^{*}} \text { by } z_{k^{*}}, P K \text { by } g^{\alpha}, P K_{0} \text { by } g^{a}, P K_{1} \text { by } g^{\beta_{1}}\),

\(P K_{2} \text { by } g^{\beta_{2}}, H_{1}\left(I D^{*}\right) \text { by } g^{x^{*}}, H_{2}\left(I D^{*} \| t^{*}-2\right) \text { by } g^{y_{t^{*}-2}}\),

\(H_{2}\left(I D^{*} \| t^{*}-1\right) \text { by } g^{y_{t^{*}-1}}, H_{2}\left(I D^{*} \| t^{*}\right) \text { by }\left(g^{b}\right)^{y^{*}} \text { and }\)

\(N^{*} \text { by } e\left(g^{\rho^{*}},\left(g^{m}\right)^{\sum_{k^{*}} \in I}\left(M_{k^{*}} v_{k^{*}}\right)\right) \text { where } g^{m} \text { is } u \text {. }\)

\(\begin{aligned} e\left(g^{\rho^{*}}, \check{\mathrm{T}}^{*}\right)=e &\left(\left(S^{*}\right)^{\rho^{*}},\left(g^{n}\right)^{\sum_{k^{*} \epsilon I}\left(z_{k^{*}} v_{k^{*}}\right)}\right) e\left(\left(g^{\alpha}\right)^{\rho^{*}},\left(g^{x^{*}}\right)^{\sum_{k^{*} \epsilon I}\left(v_{k^{*}}\right)}\right) \\ & e\left(\left(g^{\beta_{1}}\right)^{\rho^{*}},\left(g^{y_{t^{*}-2}}\right)^{\sum_{k^{*}} \epsilon I}\left(v_{k^{*}}\right)\right) \\ & e\left(\left(g^{\beta_{2}}\right)^{\rho^{*}},\left(g^{\left.y_{t^{*}-1}\right)^{\sum_{k^{*}} \epsilon I}\left(v_{k^{*}}\right)}\right)\right.\\ & e\left(\left(g^{a}\right)^{\rho^{*}},\left(g^{b}\right)^{y^{*} \sum_{k^{*} \epsilon I}\left(v_{k^{*}}\right)}\right) e\left(g^{\rho^{*}},\left(g^{m}\right)^{\sum_{k^{*}} \epsilon I}\left(M_{k^{*}} v_{k^{*}}\right)\right) \end{aligned}\)

\(\begin{aligned} \breve{\mathrm{T}}^{*}=&\left(S^{*}\right)^{n \sum_{k^{*} \epsilon I}\left(z_{k^{*}} v_{k^{*}}\right)}\left(g^{\alpha x^{*}}\right)^{\sum_{k^{*} \epsilon I}}\left(v_{k^{*}}\right)\left(g^{\beta_{1}}\right)^{y_{t^{*}-2} \sum_{k^{*} \epsilon l}\left(v_{k^{*}}\right)} \\ &\left(g^{\beta_{2}}\right)^{y_{t^{*}-1} \sum_{k^{*} \epsilon I}\left(v_{k^{*}}\right)}\left(g^{a b}\right)^{y^{*} \sum_{k^{*} \epsilon I}\left(v_{k^{*}}\right)} g^{m \sum_{k^{*} \epsilon I}\left(M_{k^{*}} v_{k^{*}}\right)} \\ \breve{\mathrm{T}}^{*}=&\left(S^{*}\right)^{n \sum_{k^{*} \epsilon I}\left(z_{k^{*}} v_{k^{*}}\right)}\left(P K^{x^{*}}\right)^{\sum_{k^{*} \epsilon I}\left(v_{k^{*}}\right)} P K_{1}^{y_{t^{*}-2} \sum_{k^{*} \epsilon I}\left(v_{k^{*}}\right)} \\ & P K_{2}^{y_{t^{*}-1} \sum_{k^{*} \epsilon I}\left(v_{k^{*}}\right)}\left(g^{a b}\right)^{y^{*} \sum_{k^{*} \epsilon I}\left(v_{k^{*}}\right)} g^{m \sum_{k^{*} \epsilon I}\left(M_{k^{*}} v_{k^{*}}\right)} \end{aligned}\)

Let V be a variable introduced to find the value of 𝑔^ab,

\(\begin{aligned} V=& \breve{\mathrm{T}}^{*}\left(S^{*}\right)^{-n \sum_{k^{*} \epsilon I}\left(z_{k^{*}} v_{k^{*}}\right)} P K^{-x^{*} \sum_{k^{*} \in I}\left(v_{k^{*}}\right)} P K_{1}^{-y_{t^{*}-2} \sum_{k^{*} \epsilon I}\left(v_{k^{*}}\right)} \\ & P K_{2}{ }^{-y_{t^{*}-1} \sum_{k^{*} \epsilon I}\left(v_{k^{*}}\right)} g^{-m \Sigma_{k^{*} \in I}\left(M_{k^{*}} v_{k^{*}}\right)} \end{aligned}\)

\(g^{a b}=V^{\left(y^{*} \Sigma_{k^{*} \epsilon I}\left(v_{k^{*}}\right)\right)^{-1}}\)

Therefore, C solves the CDH problem with a non-negligible probability. The following events are used in the calculation of probability of C’s success:

1. E₁: C does not abort in the AuditKey query

2. E₂: C does not abort in the AuthGen query

3. E₃: A generates a valid proof of possession

4. E₄: Event E4 and 𝑑𝑑∗ = 1 for the tuple \(\left(I D^{*}, t^{*}, d^{*}, y_{t^{*}}, h_{2^{*}}\right)\) in the 𝐻₂ list

\(\begin{aligned} P\left[E_{1} \wedge E_{2} \wedge E_{3} \wedge E_{4}\right] &=\lambda^{X} \lambda^{Y} \varepsilon(1-\lambda) \\ &=\varepsilon \frac{(X+Y)^{X+Y}}{(X+Y+1)^{X+Y+1}} \end{aligned}\)

Therefore, 𝑔^𝑎b can be computed and this implies that the CDH assumption is not true. So, we can say that it is not practical to produce a valid proof of possession. Hence, it is finalized that the proposed multicloud auditing scheme is resilient to the exposure of both the audit key and the update key.

Theorem 2 (Error detectability): Let n block-tag pairs be stored and c out of n block-tag pairs be challenged. If s out of n block-tag pairs are modified or deleted, then the error detection probability P_y satisfies the equation:

\(1-\left(\frac{n-s}{n}\right)^{c} \leq P_{y} \leq 1-\left(\frac{n-c+1-s}{n-c+1}\right)^{c}\)       (29)

Proof: Let Y be a discrete random variable representing the number of corrupted/deleted blocks in the challenged block list (at least one block in the challenge must match the modified/deleted block). So,

\(\begin{aligned} P_{y} &=\mathrm{P}(Y \geq 1) \\ &=1-(Y=0) \\ &=1-\left(\frac{n-s}{n}\right)\left(\frac{n-1-s}{n-1}\right)\left(\frac{n-2-s}{n-2}\right) \ldots \ldots\left(\frac{n-c+1-s}{n-c+1}\right) \end{aligned}\)

\(\text { Therefore, } 1-\left(\frac{n-s}{n}\right)^{c} \leq P_{y} \leq 1-\left(\frac{n-c+1-s}{n-c+1}\right)^{c}\)

When c = 300 and s = 1% of n, the probability of error detection is atleast 95%.

5. Performance Analysis

In Table 2, the proposed scheme is compared with three existing Identity-based schemes, Lan et al.’s scheme [17], Zhao et al.’s scheme [18] and Nithya et al.’s scheme [15] for different features. Like the proposed scheme, Nithya et al.’s scheme is resilient to the exposure of the audit key (the other two schemes are not resilient to key-exposure). So, for the time of updation of the audit key, the proposed scheme is compared with Nithya et al.’s scheme [15]. For the remaining parameters such as size of audit messages, tag generation time, proof verification time etc. the proposed scheme is compared with both Lan et al.’s scheme and Zhao et al.’s scheme since they audit multicloud data whereas Nithya et al.’s scheme does not.

Table 2. Comparison of the features of Identity-based schemes

5.1 Analysis of the size of data stored in clouds and the size of audit messages

Let F be the data file of a cloud client. The data blocks of the file are distributed to the clouds. The total amount of cloud space required for storing all the data blocks of file F and the corresponding authentication tags is estimated and analysed. Table 3 compares the size of storage and the size of the audit messages between the three schemes. The meaning of the notations used in Table 3, are as follows:

Table 3. Comparison of the data storage size and the size of audit messages

|F| - length of the data file F

|G₁| - length of an element of group G₁

|𝐺²| - length of an element of group 𝐺²

|\(Z_{q}^{*}\)|- length of an element of group \(Z_{q}^{*}\)

n - number of data blocks of F

s - number of sectors of a data block

|i| - length of a data block index

c - number of challenged blocks

m - number of challenged clouds

d - number of clients

|t|- length of a time period

In Table 3, the extra overhead n | t | in the data storage of the proposed scheme is due to the key-resilience feature and | t | is negligible compared to | 𝐺₁ | and | \(Z_{q}^{*}\)|. In Table 3, the size of the audit challenge represents the total size of all the challenge messages (which are sent from the TPA to the m clouds). The challenge message of Zhao et al.’s scheme is the smallest. This is because Zhao et al.’s scheme is not privacy-preserving (Table 2) whereas both the proposed scheme and Lan et al.’s scheme support data privacy. Compared to Lan et al.’s scheme, the challenge message is smaller in the proposed scheme. This is because to preserve data privacy, the proposed scheme generates only one element of 𝐺𝐺2 for every challenged cloud but Lan et al.’s scheme generates d × s elements of 𝐺𝐺2 for every challenged cloud. Moreover, in Lan et al.’s scheme, a cloud server called the combiner acts as a mediator between the TPA and the challenged clouds during audit, increasing the cost of communication still further. In the table, (2 \(\left|Z_{q}^{*}\right|+d s\left|G_{2}\right|\)) bytes are sent from the TPA to the combiner.

The size of the response message represents the total size of all the audit response messages (which are sent from the m clouds to the TPA). It is the smallest for Zhao et al.’s scheme ( \(\left|Z_{q}^{*}\right|<<\left|G_{2}\right|\) ) since it does not preserve data privacy (Table 2). Compared to Lan et al.’s scheme, the size of the response message is greater for the proposed scheme by (\((m-1)\left|G_{1}\right|-\left|G_{2}\right|\)) bytes. The reasons are,

- In Lan et al.’s scheme, |𝐺₁| + | 𝐺₂ | bytes are sent from the combiner to the TPA

- In the proposed scheme, every cloud server includes one more element of 𝐺₁ from the authenticator list

5.2 Analysis of Computation Time

Table 4 compares the computation time between the three schemes. In the table, T_H , T_e , T_p and T_c represent the time to compute a hash to a point in the group 𝐺₁ , exponentiation in 𝐺₁ , pairing from 𝐺₁ to 𝐺₂ and exponentiation in 𝐺₂ respectively. The remaining operations such as inverse in the group 𝐺₁ , multiplication in 𝐺₁ , multiplication in the group 𝐺₂ and operations in \(Z_{q}^{*}\) contribute negligible computation time and are therefore omitted. The proposed scheme, Lan et al.’s scheme and Zhao et al.’s scheme are simulated using the C programming language with the Pairing-Based Cryptography (PBC) Library version 0.5.14 [30] in the following environment:

Table 4. Comparison of computation time

• OS: Ubuntu Linux 17.04

• CPU: Intel(R) Core(TM) i5 CPU 650 @ 3.20 GHz

• Physical Memory: 4.00 GB RAM

Type ‘A’ pairing is used for testing. So, | 𝐺₁ | = 128 bytes, | 𝐺₂ | = 128 bytes and |\(Z_{q}^{*}\)| = 20 bytes. | F | = 2 GB and the file is divided into 1,000,000 data blocks. Each data block is 2 KB in size and is divided into 100 sectors (i.e., s = 100) of equal size.

The time of updating the audit key is the time taken together by both the TimeKeyGen and the AuditKeyUpdate algorithms. As seen in Fig. 5, the time in the proposed scheme and Nithya et al.’s scheme is similar except for t = 0. For t = 0, the proposed scheme requires two more hash to a point in 𝐺₁ and two more exponentiation operations (2 T_H + 2 T_e ) than Nithya et al.’s scheme. This is due to the resilience feature of the proposed scheme to the exposure of both the audit key as well as the update key (Table 2). Whereas Nithya et al.’s scheme collapses in the case of exposure of both the keys.

Fig. 5. The time of updating the audit key

It can be seen from Fig. 6, that the tag generation time of the proposed scheme is lesser compared to the existing schemes since its AuthGen algorithm replaces the costly hash to an element of 𝐺₁ by hash to an element of \(Z_{q}^{*}\) . Comparatively, the time is much higher for Lan et al.’s scheme due to greater number of exponentiations (in Table 4, n(s + 1)T_e > (2n + 1)T_e ).

Fig. 6. The Tag Generation time

Let c be the number of challenged blocks. Fig. 7 and Fig. 8 depict the time taken to generate the audit challenge messages for m = 10 clouds with d = 1 client and d ≥ 50 clients respectively. Zhao et al.’s scheme is not privacy-preserving and so its challenge generation algorithm does not contain any of the major operations (mentioned above). Hence, the time consumed by Zhao et al.’s scheme is very minimal and is therefore omitted in Table 4 and in the figures. In both the figures, the time taken by the proposed scheme is constant and is much lesser than Lan et al.’s scheme. This is because, the proposed scheme requires lesser number of exponentiations and pairing operations (T_e and T_p ) than Lan et al.’s scheme (Table 4).

Fig. 7. The Challenge Generation time. Here 10 clouds (i.e., m = 10) are challenged. exponentiation in

Fig. 8. The Challenge Generation time in batch auditing. Here, 10 clouds are challenged with c = d × 100 data blocks.

Fig. 9 and Fig. 10 illustrate the total time taken by m = 10 clouds to generate the audit response messages with d = 1 client and d ≥ 50 clients respectively. Here, the proof generation time of Lan et al.’s scheme and the proposed scheme are almost similar and also higher than Zhao et al.’s scheme. This is also due to the same reason that Zhao et al.’s scheme is not privacy-preserving.

Fig. 9. The Proof Generation time of 10 clouds

Fig. 10. The Proof Generation time of 10 clouds in batch auditing. Here, c = d ×100 data blocks.

Fig. 11 and Fig. 12 portray the time taken to verify the audit proof messages of 10 clouds (m) with d = 1 client and d ≥ 50 clients respectively. In both the figures, the proof verification time of the proposed scheme is much lesser than the other two schemes due to lesser number of hash to an element of 𝐺𝐺1 and exponentiations. (c >> d, T_c < T_p , T_c < T_e and T_c < T_H in Table 4).

Fig. 11. The Proof Verification time. The audit proof from 10 clouds are verified.

Fig. 12. The Proof Verification time in batch auditing. Here, m = 10 clouds and c = d ×100 data blocks.

6. Conclusion and Future Work

In this paper, an Identity-based PDP scheme with parallel key-insulation is proposed for multicloud storage. To our knowledge, it is the first key-exposure resilient scheme in distributed cloud storage auditing. It reduces the risk of exposure of update keys. The update key is a secret key used to update the auditing secret key (audit key). Our scheme will not fail, even if some of the update keys and some of the audit keys are both exposed. It protects the privacy of data during third party auditing and is also secure against malicious Cloud Service Providers. The scheme is extended further, to handle auditing delegations from multiple clients using a batch approach.

Both the numerical and the experimental analyses show that the proposed scheme can efficiently verify the integrity of cloud data. Although the proof generation time of the proposed scheme and Lan et al.’s scheme are similar, our proposed scheme has the added advantage of being resilient to keyexposure whereas Lan et al.’s scheme is not.

Our future work is to extend the above scheme to provide intrusion resilience i.e., change the update key in every time period. This is to strengthen the security of auditing even if many of the update keys and many of the audit keys are both exposed.