Certificateless Reliable and Privacy-Preserving Auditing of Group Shared Data for FOG-CPSs

FOG-enabled cyber-physical systems (FOG-CPSs) open new security challenges as the local edge devices are easier to compromise than a traditional cloud server. Remote data integrity checking (RDIC) plays an important role in safeguarding against data corruption from a storage server. Certificateless cryptography (CLPKC)-based RDIC schemes do not suffer from the drawbacks of the public key infrastructure (PKI)-based RDIC protocols. Most of the CLPKC-based RDIC schemes proposed in the literature deal with personal data. However, in a FOG-CPS, it is also important to audit a data file shared by a group of edge devices. Most of the existing group shared data auditing schemes lack mechanisms to defend against a semi-trusted data auditor applicable for a FOGCPS scenario. In order to address these issues, in this paper, we propose a novel CLPKC-based group shared data auditing protocol tailored to the specific security requirements of a FOG-CPS. Besides, we perform a detailed cryptanalysis of two existing CLPKCbased privacy-preserving group shared data auditing schemes. )e formal security analysis of our proposed protocol establishes metadata and data integrity proof unforgeability and claimed zero-knowledge privacy and reliability properties through rigorous proofs in the random oracle model setting. Performance evaluations establish the efficiency of our proposed protocol.


Introduction
After the introduction of FOG computing by Cisco [1], considering the capability of FOG to provide computing at the edge of the network while preserving the advantages of cloud computing such as ubiquity, decentralized management, and so on, FOG-assisted CPS (FOG-CPS) [2][3][4][5][6][7][8] is emerging as a new research domain to address the data management issues of CPS. e ability of FOG-CPS to provide services at the physical proximity of the network is very much useful in ensuring the low-latency and reliability requirements of the real-time jobs in a CPS. However, it opens new security challenges since the local edge devices are much easier to compromise by an attacker than a traditional cloud server, and hence it cannot be fully trusted. Resource limitations of the edge devices offer additional challenge in designing security protocols for a FOG-CPS.
Ensuring the availability of correct data at the right time is of utmost importance for a safety-critical CPS. Data auditing plays an important role in safeguarding against intentional or unintentional deletion or modification of data from a cloud data storage. Since the stored data are enormous, retrieving the complete file to check data integrity is impractical in communication and computation costs [9]. A large number of remote data integrity checking (RDIC) protocols have been proposed in the literature  which enable a cloud user to verify the integrity of data files stored at the cloud server remotely. An RDIC protocol involves two phases, namely, (a) preprocessing phase: in which, a cloud user, using its security credentials, generates some metadata from the data blocks of its data file and then outsources the metadata along with the data file to the cloud service provider (CSP), and (b) verification phase: in which, a trusted data auditor sends a challenge message to the CSP, who computes a proof of possession on the challenged data file using the stored metadata and data. e auditor verifies the proof generated by the CSP to determine the integrity of the stored data file [41]. Majority of the RDIC protocols proposed in the literature [11, 12, 26-31, 33, 34, 38, 40] deal with personal data where a data file is solely owned by a single cloud user. However, in a FOG-CPS scenario, group of edge devices, either located in a specific geographical area or are dedicated for some specific task, forms a cluster, and data collected or generated by all edge devices in a cluster are kept in a single data file so that it can be efficiently accessed by all the others in the cluster. Auditing of such shared data file imposes additional challenges since the metadata for different blocks of the same data file may now be generated by different users (edge devices) using their own security credentials, and hence, while auditing, the CSP needs to aggregate all such heterogeneous pieces of information.
A good number of RDIC protocols have also been proposed by the researchers for auditing group shared data [10, 13-25, 32, 35-37, 39]. Some of these schemes, such as [10,42], are dependent on the traditional public key infrastructure (PKI)-based system where a trusted certification authority (CA) is responsible for managing and distributing public key certificates of all the users and the certificate revocation lists (CRLs). Although PKI-based security protocols serve excellent in traditional networks such as the Internet, they are inefficient in a ubiquitous network like FOG-CPS. For a resource-constrained edge device, it is impractical to store and verify public key certificates associated with the large number of edge devices in a FOG-CPS. Moreover, obtaining up-to-date certificates and CRLs from the CA might be problematic for the edge devices since the devices might be deployed in an area having intermittent Internet connectivity. To address the problems associated with PKI, a number of shared data auditing protocols [13][14][15] have been proposed based on identity-based cryptography (IBC). In IBC [43], the public key of an user is derived from the publicly known identity of the user, and hence it does not suffer from the complexities of certificate management problems of a PKI-based system. However, in all IBC-based shared data auditing protocols [13][14][15] and in the protocols proposed in [44], where the private key of an user is generated by a trusted private key generator (PKG), the security of the whole system gets collapsed when the PKG gets compromised. is problem of IBC is known as the key escrow problem, in literature [45]. e certificateless cryptography (CLPKC) [45] was introduced to eliminate both the key escrow problem of IBC and the certificate management problem of PKI at the same time. In CLPKC, like IBC, the authenticity of the public key of an user is implicit; however, the full private key of an user is known only to that user. Recently, a number of CLPKC-based shared data auditing protocols have been proposed in the literature [16][17][18][19][20][21][22][23][24]39] for traditional cloud storage systems. However, these protocols cannot be directly adopted for a FOG-CPS because of its discriminating characteristics as discussed below.
In FOG-CPS, the data storage and computing facilities are brought close to the CPS network for efficient bandwidth utilization and faster communication [46,47]. Hence, implementing a data auditing protocol for a FOG-CPS allows the best utilization of FOG computing benefits when the data auditor is part of the edge network. is motivates us to design a protocol where we can opt an edge device from the CPS network to perform the data auditing task to improve FOG-CPS network latency and performance. However, since an edge device is susceptible to compromise either by physical tampering or through security attacks, we cannot fully trust the data auditor in this scenario. Here, we identify the two main security vulnerabilities that may arise from such a semi-trusted data auditor. First, ensuring confidentiality of the data is as important as ensuring its availability for a safety-critical CPS. Hence, a data auditing protocol designed for such scenario must ensure that no information regarding the content of the data file is leaked to the semi-trusted data auditor during its interactions with the storage server. e second concern is regarding the reliability of the auditing service provided by a semi-trusted data auditor. e reliability of the auditing service may be hampered due to two possible reasons, namely, (a) selfish nature of the auditor device and (b) collusion between CSP and the auditor. e data auditor is supposed to perform auditing duties on the request of the users (other edge devices) and periodically, as per the frequency specified in a service-level agreement (SLA). But, the edge device acting as auditor may behave selfishly to save its computational resources by either skipping or delaying the auditing tasks. Moreover, if the auditor is compromised by the storage server, that is, if there exists a collusion between the data auditor and the CSP, the auditor may disclose all the challenge vectors in advance to the CSP, using which, the storage server can precalculate data possession proofs and then delete/modify the data blocks of the data file. e threat of auditor-CSP collusion was first identified by Armknecht et al. for non-shared data auditing protocol [48], without data privacy against auditor, proposed for a traditional cloud storage system. In a traditional RDIC protocol, it might not be considered a serious threat as the possibility of collusion between the CSP and data auditor may be negligible. However, in a FOG-CPS scenario, where an edge device is supposed to work as the auditor and the storage server is also part of the edge network, the chances of an auditor being compromised by the storage server cannot be neglected. e CLPKC-based group shared data auditing protocols proposed in [16][17][18][19][20][21][22] trust the data auditor on the data confidentiality and hence do not provide any data privacy mechanisms against the auditor. In these protocols, the auditor can extract the data blocks from the information received from the cloud as part of the data auditing process.
Recently, a few privacy-preserving CLPKC-based shared data auditing protocols have been proposed by the researchers [23,24,39] for traditional cloud storage systems. But, none of these schemes can ensure the reliability criteria of the auditing service against a semi-trusted data auditor in a FOG-CPS, as defined above.
Moreover, the schemes in [23,24] employ a weaker notion of data privacy which only ensures that a compromised auditor will not be able to extract any information regarding the challenged data blocks from the data possession proofs received from the CSP. However, the data possession proofs sent by the CSP leaks information regarding the metadata corresponding to the challenged 2 Security and Communication Networks blocks, since the CSP does not employ any masking technique to hide the part of a data possession proof computed from the metadata. A compromised data auditor can use this leaked information to perform an offline guessing attack to find a valid message block corresponding to the leaked metadata. Furthermore, our cryptanalysis shows that the metadata generation mechanisms used in [23,39] cannot fully protect the integrity and authenticity of metadata, corresponding to a data block, generated by an user. In these schemes, an attacker having access to a valid data block along with its corresponding metadata can easily replace the data block with a forged block. Uploading the data and the metadata blocks using a confidential channel between the user and the CSP can prevent access to the metadata blocks against unauthorized entities. However, we cannot prevent the CSP itself to get access to the data and metadata blocks as those are essential for the calculation of correct data possession proofs by the CSP. A compromised CSP can always launch the abovementioned attack by replacing the public key of the user, which is also known as type-I attack in CLPKC literature [45]. To mitigate this problem, an user may explicitly authenticate its public key using some mechanisms such as digital signature. However, this would contradict with the main purpose of CLKPC, which is to authenticate public keys implicitly without use of any explicit signature or certificates.
In this paper, our contribution is twofold. First, we have performed a detailed cryptanalysis of the CLPKC-based privacy-preserving shared data auditing schemes proposed in [23,39] to pinpoint the exact vulnerabilities in the metadata generation mechanisms used in these protocols. Second, to address the limitations of the existing research as discussed above, we have proposed a novel group shared data auditing protocol tailored to the specific security requirements of a FOG-CPS. e proposed data auditing protocol takes advantage of the localized storage and computing facilities available at the edge of the FOG-CPS network by delegating an edge device geographically close to the storage resources to perform the data auditing task. Our protocol ensures zero-knowledge data privacy [49] against a semi-trusted data auditor where the auditor can learn no information regarding either a data block or a metadata block corresponding to a data file while auditing for the integrity of the file. e proposed protocol is also reliable against a semi-trusted data auditor. It enables a user to verify the data auditing reports generated by the auditor and detect any procrastination of auditing tasks done by the auditor. In order to defend against possible collusion of auditor and the CSP in advance on the challenge vectors, we ensure that the challenge vectors are generated from a time-varying and verifiable universal source of randomness. We have designed our protocol using the CLPKC mechanism, and hence it is free from both the certificate management problem associated with traditional PKI as well as the key escrow problem associated with IBC. We have performed a detailed security analysis of our proposed protocol. We have proved that the metadata generated by our protocol are unforgeable even by a CSP. To be specific, the metadata generation mechanism used in our protocol is secure against both type-I and type-II attacks in the random oracle model setting, as per the security notions defined in certificateless cryptography [45]. We have also established proofs in support of the claimed zero-knowledge privacy (ZKP) and the reliability properties of our proposed protocol. e comparative performance evaluations establish the efficiency of our proposed protocol. e rest of the paper is organized as follows. We review the literature in Section 2, which covers generic remote data integrity checking protocols, and the research related to FOG-CPSs. In Section 3, we provide the necessary preliminary concepts and security model required for the proposed work. In Section 4, we show the detailed cryptanalysis of the schemes in [23,39]. In Section 5, we provide detailed information about the entities involved, data structures and files used, and the assumptions underlying our proposed scheme. In Section 6, we describe in detail the proposed basic CLS-RDIC scheme. In Section 7, we describe in detail the proposed CRPPA scheme. Section 8 presents a detailed security analysis of both the proposed basic CLS-RDIC and CRPPA schemes. In Section 9, we provide qualitative and experimental computation cost comparisons of our proposed CRPPA scheme with some other existing schemes. Section 10 concludes the paper. Table 1 shows the list of acronyms and their abbreviations used throughout the entire paper.

Related Work
In this section, we first provide a brief summary of the research done in the field of FOG-CPSs, their importance, and the need for security in FOG-CPSs. After this, we survey the existing remote data integrity checking (RDIC) protocols proposed for cloud storage services and discuss their applicability for FOG-CPSs.

FOG-CPSs.
ere is a massive increase in the number of cyber-physical system (CPS) devices connecting to the Internet to access cloud computing services. With the current growth rate, the available bandwidth of the cloud computing system will not be able to cater to the growing demand, and this situation increases the latency of the cloud computing network [47]. To overcome the bandwidth and latency issues in a traditional cloud computing environment, Cisco proposed a new cloud computing paradigm called FOG computing [1]. In FOG computing, FOG nodes are deployed in less centralized geographically close locations to end-user devices (CPS devices) to provide storage and computing facilities, improving bandwidth and latency issues. Since the FOG-CPS devices are less centralized, they are prone to physical tampering and security attacks. erefore, there is a strong security requirement regarding the confidentiality, integrity, and availability of data for the FOG-CPS [2,50,51].
Several works have been proposed to provide security for the critical data of CPS devices in FOG-CPSs. e authors in [3] employed a modified version of the attributed-based encryption technique to provide secure communication between the FOG-CPS devices even when the certificate authority is comprised. e scheme in [4] employs a Security and Communication Networks lightweight signature mechanism to generate group signatures, which helps to handle batch authentication of edge nodes efficiently. e authors in [5] provided a framework for the user and data privacy in the FOG-enabled smart city network. e schemes in [6,7] provide mechanisms for privacy-preserving secure data aggregation mechanisms for FOG-CPSs. In [8], FOG nodes store cache data to improve the edge network latency; the scheme employs a modified version of a Merkle hash tree data structure to enable end users to audit the integrity of their cached data. Chen et al. [52] proposed a lightweight pairing-free CLPKC-based matchmaking encryption mechanism for secure communication in the Internet of things (IoT) to prevent leakage of information and identity forgery. Further, the data sharing mechanisms in scheme [52] are efficient, and the authors have provided formal security proofs of the protocols based on the standard hard assumptions. e scheme in [53] provides mechanisms to establish a group shared key for secure data sharing and storage in CSP and can be adopted to FOG-CPS networks. e authors in [54] designed a CLPKC-based searchable encryption technique for an honest-but-curious platform to provide secure data sharing in an industrial IoT environment against keyword guessing attacks. e scheme in [54] is secure against a malicious key generation center, provides user data security and access control on search, and supports on-demand user revocation.
Further, many FOG-CPS schemes have been proposed to take advantage of blockchain technology, but the devices in the FOG-CPS are resource-limited, and they cannot directly adopt the traditional blockchain. erefore, the works in [55][56][57][58] developed scalable public blockchain techniques for FOG-CPSs. e authors in [57] proposed a group chain concept which utilizes a two-chain structure to build the blockchain for regulating the behaviour of groups and preventing malicious nodes from performing joint attacks. e authors in [58] constructed a Ethereum blockchain for the resource-constrained device to provide security of the data generated from the CPS devices. ey even designed a secure networked clock for blockchain data synchronization for the non-real-time CPS devices.

Remote Data Integrity Checking (RDIC) Protocols.
Blum et al. [59] introduced the first RDIC scheme in which the data owner maintains a small amount of metadata corresponding to the actual outsourced data, and using these metadata, the data owner checks if the actual data stored remotely are intact or corrupted. Ateniese et al.'s RDIC scheme [9] generates probabilistic provable data possession (PDP) proofs where the data verifier checks the data integrity of a file by only verifying the validity of a few random data blocks of the file. In the probabilistic PDP schemes, the cloud user splits the data file into several smaller blocks, and each block is denoted with an index. For each of the data blocks, the cloud user computes metadata using its security credentials. e cloud user then uploads both the data file and metadata to the cloud server and deletes the original data file from its storage. Suppose the cloud user wants to verify the integrity of the remote data file. e user initiates a challenge-response protocol to the CSP, in which the user sends a challenge set that contains some random indices corresponding to the data blocks of the data file. e CSP computes a PDP proof corresponding to the challenge set and sends the PDP proof as a response to the cloud user. e cloud user verifies the PDP proof and determines whether the integrity of the remote data file is intact or corrupted. Juels et al. [60] proposed a symmetric-key-cryptographybased RDIC scheme called the proof of retrievability (POR) that utilizes efficient error-coding techniques. e main drawback of the scheme is that it supports only private verification. e authors in [32] provided a POR mechanism based on BLS signature [61] that supports public verification but implicitly suffers from data privacy issues against the public verifier. e majority of public key cryptography-based RDIC protocols [11, 12, 26-30, 33, 34, 37, 40] developed until now employ PKI or IBC [43]. e PKI-based RDIC schemes [11,30,37] require the user to verify the certificate of the other user for authentication each time before initiating a communication. e PKI has a very high computational and communication overhead, and introducing the PKI into an RDIC scheme certainly overloads the users in terms of required computation power. On the other hand, the ID-based RDIC schemes [12, 26-29, 33, 34, 40] are efficient in terms of computation and communication overhead than PKI.
Zhao et al. [33] introduced the first ID-based RDIC scheme that ensures public verification of remote data integrity and provides privacy against a third-party auditor (TPA). Wang et al. [34] developed the first IBC-based RDIC for the multi-cloud storage model. Yu et al. [12] proposed a secure symmetric key agreement between the three parties of a public RDIC protocol, namely, the cloud user, the public verifier (auditor), and the CSP, to provide data privacy against the public verifier efficiently. Still, their tag-generation mechanism is susceptible to the attacks shown in Section 4 and hence is not secure. Zhang et al. [25] improved the scheme in [48], but it lacks data privacy. e IBC-RDIC schemes have an inherent key escrow problem where the private key of a user is generated using the master secret key of the PKG. e compromise of the master secret key of the PKG will result in a compromise of the security credentials of all the users. us, the encrypted communication under a user's public key gets exposed. Certificateless public key cryptography (CLPKC) [45] eliminates the burden of certificate management of PKI and the key escrow problem of IBC.
A number of existing RDIC schemes in the literature [11, 12, 26-30, 33, 34, 40] deal with personal data where a data file is solely owned by a single cloud user. However, in a FOG-CPS scenario, group of edge devices, either located in a specific geographical area or are dedicated for some specific task, forms a cluster, and data collected or generated by all edge devices in a cluster are kept in a single data file so that it can be efficiently accessed by all the others in the cluster. Auditing of such shared data file imposes additional challenges since the metadata for different blocks of the same data file may now be generated by different users (edge devices) using their own security credentials, and hence, while auditing, the CSP needs to aggregate all such heterogeneous pieces of information. A number of schemes that support group shared data include [10, 13-25, 32, 35-37, 39].
We now focus on the CLPKC-based group shared data schemes considering the advantages of CLPKC over IBC and PKI. e CLPKC-based group shared data auditing protocols proposed in [16-22, 62, 63] are not data privacy-preserving. Further, Li et al.'s [62] metadata generation mechanism suffers from metadata forgeability. Jaya et al.'s [63] scheme on certificateless multi-replica RDIC considers the fully trusted KGC and TPA. In reality, the TPA or KGC should not gain any sensitive or confidential information about the cloud user. A few recently proposed privacypreserving CLPKC-based group shared data auditing protocols [23,24,39] employ traditional cloud storage systems, and these schemes cannot ensure the reliability criteria of the auditing service against a semi-trusted data auditor. e schemes in [23,24] employ a weaker notion of data privacy where the data possession proofs sent by the CSP leak information regarding the metadata corresponding to the challenged blocks. Further, the schemes [23,39] are susceptible to metadata forgery attacks discussed in Section 4.
In summary, the adoption of FOG computing across various CPS domain areas to address the data management issues is exponentially growing, and ensuring the availability of correct data at the right time is of utmost importance for a safety-critical CPS. us, the need arises for remote data integrity checking (RDIC) mechanism for FOG-CPSs. However, many RDIC schemes proposed in the literature employ ID-based cryptography (IBC) with an inherent key escrow problem [12, 26-29, 33, 34, 40] or depend on public key infrastructure (PKI) for key management, which is expensive [11,30,37]. Certificateless cryptography (CLPKC)-based RDIC schemes overcome the drawbacks of IBC and PKI mechanisms. However, several CLPKC-based RDIC schemes have been proposed in the literature to deal only with personal data. But, in a FOG-CPS scenario, a group of edge devices performs some specific task and forms a cluster. Data generated by all edge devices in a cluster are kept in a single data file so that all others can efficiently access it in the cluster. Hence, RDIC schemes [11, 12, 26-30, 33, 34, 40] designed for personal data auditing cannot be adopted for FOG-CPS scenarios. Although there are few existing CLPKC-based group shared data auditing schemes, none of these schemes [16-22, 62, 63] provide mechanisms to ensure confidentiality of user data and reliability of data auditing task against a semi-trusted data auditor at the same time, which are essential for a FOG-CPS. erefore, we have proposed a CLPKC-based group shared data auditing protocol that ensures zero-knowledge data privacy against a semi-trusted data auditor where the auditor can learn no information regarding either a data block or a metadata block corresponding to a data file while auditing for the integrity of the file. At the same time, the proposed protocol also ensures the reliability of the auditing task by a semi-trusted data auditor where the auditor cannot collude with the CSP in advance on the random challenge vectors used as a part of RDIC and cannot delay or skip the auditing tasks. To the best of our knowledge, integrating both the confidentiality and the reliability objectives, as defined above, have not been addressed by any of the existing CLPKC-based group shared data auditing protocols.

Preliminaries
In this section, we discuss the preliminary concepts which have been used as the building blocks to design the proposed protocol. At first, we introduce the negligible function, the general forking lemma [67], and the concepts of bilinear map and computational Diffie-Hellman (CDH) problem. We then provide the outline of a certificateless signature (CLS) scheme which is a part of certificateless cryptography (CPLKC) [45] used in our protocol for metadata generation purpose. In the last two subsections, we first provide an overview of a CLS-based RDIC scheme and then describe the standard adversary model used by the researchers to analyze the security of these schemes.

Negligible Function (ξ). A function ξ(x):
In cryptography, a scheme is said to be "provably secure," if the probability of security failure is a negligible function of the input x which is the security parameter (cryptographic key length) of the security scheme. [67]. Let x be a set of global parameters and H be the co-domain of a random oracle function RO, with |H| ≥ 2. Let A be a randomized algorithm which takes x and a set h Forking. e forking protocol on algorithm A, denoted as Fork A (x), is as shown below:

General Forking Lemma
(1) $ ← Random Tape; e above protocol Fork A (x) actually consists of two rounds. In the first round, we input the value of x, a randomly chosen set of h 1 , . . . , h v values, and a random tape $. e protocol aborts and returns 0 if algorithm A does not accept (I � 0) the inputs in the first round. In the second round, we provide the same x and $ values to algorithm A; however, the input set h 1 , . . . , h v is updated keeping h 1 to h I− 1 the same. e second round aborts and returns 0 if either the acceptance indices I and I ′ of the two rounds are different or if the randomly generated elements h I and h I ′ are same. Otherwise, the protocol Fork A (x) returns 1. It can be noted that the main objective of the forking protocol is to generate two different side output values θ and θ ′ using two different random oracle values h I and h I ′ .
Forking Probability. e forking probability for the above protocol Fork A (x) is defined as Pr[frk] � Pr[Fork A (x) � 1] where x is a randomly generated global parameter x.

Bilinear Map.
Consider two cyclic multiplicative groups G 1 , G 2 , for |G 1 | � |G 2 | � q, where q is a large prime integer. A bilinear map [61] is a function of the form e: G 1 × G 1 ⟶ G 2 , that satisfies the following properties. Bilinearity.
Non-Degeneracy. e(X, Y) ≠ 1 for all values of X and Y, where 1 is the identity element of G 2 .
Computability. ere exists a polynomial-time algorithm to compute e. e bilinear map can be implemented using a Weil pairing [43] or a Tate pairing [68].

Computational Diffie-Hellman (CDH) Problem.
Let G 1 be a cyclic multiplicative group of order q, and let g be the generator of the group. e CDH problem [69] in G 1 is as follows: given 〈q, G 1 , g, h 1 , h 2 〉 for some h 1 , h 2 ∈ G 1 , where h 1 � g α and α ∈ Z q * , compute h 2 α . e decision version of the above problem, also known as the decisional Diffie-Hellman (DDH) problem, is defined as follows: given 〈q, G 1 , g, h 1 , h 2 , h 3 〉 for some h 1 , h 2 , and h 3 ∈ G 1 , where h 1 � g α , h 2 � g β , and h 3 � g c , for α, β, c ∈ Z q * , decide whether g αβ � g c . e DDH problem is easy to decide in G 1 if there exists a bilinear map in group G 1 . However, till date, there exists no efficient algorithm to compute h 2 α in polynomial time, and thus CDH is believed to be a hard problem in group G 1 .

Certificateless Signature Scheme.
A certificateless signature (CLS) scheme is part of the CLPKC mechanism [45], which is used to generate and verify digital signatures without the use of any public key certificates. In order to defend against the key escrow problem, CLPKC uses the concept of partial keys where part of the private key of an user is generated by a trusted key generation center (KGC) and the rest of the part is generated and known to the user only. A CLS mechanism consists of the following seven algorithms: (i) Setup: it is a probabilistic polynomial-time (PPT) algorithm that takes a security parameter k as input and outputs public parameter-list params and a secret master key (α) for the key generation center (KGC). e KGC executes the algorithm and announces the public parameters params to all the participating entities. (ii) Partial-Private-Key-Extract: the KGC runs this algorithm at the request of the user to generate a partial-private key for it. e user sends its identity ID u to KGC as part of the request. e input to this deterministic polynomial-time (DPT) algorithm is the identity ID u , public parameters params, and master secret key α, and it outputs the partial-private-key D u . e KGC transfers the partial-private-key D u to the corresponding user through a secure side channel. (iii) Set-Secret-Value: this algorithm is executed by a user u. e input to this PPT algorithm is params and ID u and it outputs a secret value β u which is kept secret to the user u only. (iv) Private-Key-Gen: a user u runs this PPT algorithm to generate its private key as 〈D u , β u 〉. (v) Set-Public-Key: user u runs this DPT algorithm with its identity ID u , full private key 〈D u , β u 〉, and the public parameters params as the inputs to generate its public key P u . User u announces its public key publicly without the need for any certificate. (vi) Sign: this PPT algorithm is executed by a user u to generate a signature on a given message m ∈ 0, 1 { } * . e algorithm takes m, ID u , the full private key 〈D u , β u 〉, and the public parameters params as the inputs and produces Sig m as the signature. (vii) Verify: the input to this DPT algorithm is m, Sig m , params, ID u , and P u and outputs accept if the signature is valid, or reject otherwise. e algorithm can be executed by any entity having the required inputs in its hand.
A CLS scheme can be considered as secure only if there is no existential forgery possible for signatures, either by (a) any compromised user who can try to achieve this by replacing the public key of another user or (b) even by a compromised but passive attacker KGC. Type-I and type-II attackers are defined in Section 3.7 which describes these two attack scenarios in detail.

Overview of a CLS-RDIC Scheme.
A CLS signature-based remote data integrity checking (CLS-RDIC) scheme consists of four types of entities (roles), namely, (i) cloud user (data owner), (ii) the cloud service provider (CSP), (iii) a trusted third-party auditor (TPA), and (iv) the KGC. It consists of eight algorithms: the CLS mechanism, as described in Section 3.5, contributes the first four algorithms, namely, setup, partial-private-key-extract, private-key-gen, and setpublic-key. e rest of the algorithms of CLS-RDIC are briefed below: (i) Tag-Gen: a cloud user runs this algorithm with a data block m, corresponding authenticating information w � (file-id ‖block − index‖ public info. of user), params , and ID u as inputs to generate a tag (σ), where m ∈ M, for M is the message space. For every data block uploaded in the data file ID F , the value w is updated in a public log file. Set of all tags corresponding to all the blocks of the data file constitutes the metadata, stored by the CSP along with the original data file. (ii) Challenge: the TPA runs this algorithm with c (number of data blocks challenged), ID F (id of the data file), params, and inputs from a pseudorandom source to generate a challenge vector called chal. e chal contains information regarding the specific blocks challenged, along with some random values, for which the CSP needs to generate a data integrity proof. (iii) Proof-Gen: the CSP runs this DPT algorithm when it receives a challenge request chal from the TPA. e inputs to this algorithm are chal, params, σ i , and m i (all tags and data blocks corresponding to the challenge), and it outputs data integrity proof P for the challenged blocks. (iv) Proof-Ver: the TPA runs this DPT algorithm with the inputs P, chal, ID F , and params and outputs accept if the proof P is valid, or reject otherwise. e security requirements for a CLS-RDIC scheme are discussed in detail in the following subsection.

Security Model for a CLS-RDIC Scheme.
A CLS-based RDIC scheme is considered to be secure only when (a) the underlying CLS mechanism is secure, i.e., when the generated tags are unforgeable by any internal or external attacker, and (b) the CSP is unable to cheat the TPA, i.e., when CSP can pass the auditing test only if it stores all the data blocks of a file correctly. According to the CLPKC literature [45], the tag unforgeability is again considered against two different types of attackers, namely, (i) type-I attacker: any internal/external attacker except the KGC, and (ii) type-II attacker: a compromised KGC. A compromised CSP that aims to cheat the TPA is termed as type-III attacker. We use the random oracle model (ROM)-based analysis [70] to validate the security of a CLS-RDIC scheme against the three types of attackers defined above. In the random oracle model-based analysis, the hypothetical attacker's power and the proposed protocol's ultimate security objectives are modeled as a game between the attacker and a challenger. e games corresponding to the above three types of adversaries are defined in the following three subsections.

Type-I Adversary (Adv1).
In type-I attack, the adversary may be an external attacker or an internal attacker such as a compromised user/users or even the CSP. e objective of the attacker is to generate a valid tag for a forged data block for a data file corresponding to a victim user. It is quite obvious to assume that the adversary has access to all the public parameters used in the protocol including the valid public keys of all genuine users. Since the adversary may be a compromised user/users, it may have valid partialprivate-keys and personal secret-values corresponding to a set of legitimate users. Additionally, an adversary may have access to valid tags corresponding to a set of data blocks, generated by the victim user using its valid security credentials. e adversary may obtain this information either by eavesdropping to the communication between the victim user and CSP during metadata upload phase or when the adversary is the CSP itself. However, we assume that, in any case, the personal secret value of the victim user is not Security and Communication Networks 7 known to the adversary. Since there is no use of public key certificates in a CLS-RDIC scheme, attacker may try to replace the public key of the victim user by advertising a false public key claiming it as the public key of the victim user. Game-1, defined below, between a challenger (C) and an adversary Adv1, models the hypothetical type-I attacker discussed above. e game consists of the following phases.
Setup. e challenger C runs the setup algorithm of the CLS-RDIC scheme to generate the master secret key msk and public parameters params. C forwards only the params to Adv1 and keeps with itself msk.
Queries. In this phase, Adv1 can adaptively make the following queries to the challenger C.
(i) Hash Query: Adv1 can query for hash values of any binary string, related to any hash function used for tag generation in the CLS-RDIC scheme, to the challenger C. C is required to send back the correct output. (ii) Partial-Private-Key Query: Adv1 can submit any identity ID u to C. C runs the Partial-Private-Key-Extract algorithm of the CLS-RDIC scheme to provide the corresponding partial private key to Adv1. (iii) Secret-Value Query: Adv1 can submit any identity ID u to C. Challenger C runs the Set-Secret-Value algorithm of the CLS-RDIC scheme to provide the corresponding secret value to Adv1. (iv) Public-Key Query: Adv1 can submit any identity ID u to C. Challenger C runs the Set-Public-Key algorithm of the CLS-RDIC scheme to provide the corresponding public key to Adv1. (v) Public-Key-Replacement Query: Adv1 can submit any identity ID u and a public key P u ′ of its choice to C. Challenger C updates the public key corresponding to ID u as P u ′ . (vi) Tag-Gen Query: Adv1 can submit any tuple (m, w, ID u ) of its choice to C. Challenger C runs the Tag-Gen algorithm of the CLS-RDIC scheme to generate the corresponding tag σ and sends the tag to Adv1.
Adv1 wins game-1 only if (i) σ ′ is valid tag corresponding to the forged data block m ′ and the authenticating information w ′ for the targeted user ID u ′ , (ii) Adv1 has not queried for the secret value corresponding to the identity ID u′ , (iii) Adv1 does not query for the partial-private-key and replace public key simultaneously for the identity ID u ′ , and (iv) Adv1 has not queried the tag for the (m ′ , w ′ , ID u ′ ) tuple at any stage.

Type-II Adversary (Adv2).
In type-II attack, we consider a compromised KGC as a passive attacker in the sense that it may try to forge a data block for a victim user but without any attempt to replace the public key of the victim user. Like type-I attacker, we assume that the adversary has access to all the public parameters used in the protocol including the valid public keys of all genuine users. Additionally, since the attacker is the KGC itself, it has access to the master secret key msk of the KGC. Like type-I attack scenario, adversary may have access to valid tags corresponding to a set of data blocks, generated by the victim user using its valid security credentials. Similar to type-I attacker, we assume that the personal secret value of the victim user is not known to the adversary. However, unlike a type-I attacker, the adversary does not try to replace the public key of the victim user.
Game-2, defined below, between a challenger (C) and an adversary Adv2, models the hypothetical type-II attacker discussed above. e game consists of the following phases.
Setup. Challenger C runs the setup algorithm of the CLS-RDIC scheme to obtain the master secret key msk and public parameters params. C forwards both msk and params to Adv2.
Queries. In this phase, Adv2 can make the following queries adaptively to challenger C. It can be noted here that we do not include the Partial-Private-Key Query for Adv2 since it can calculate the partialprivate-key of any user using msk it has in its possession.
Forge-Tag. Finally, Adv2 outputs a tuple (σ′, m ′ , w ′ , ID u ′ ), where σ ′ is the forged tag on the forged data block m ′ with authentication information w ′ for user ID u ′ .
Adv2 wins game-2 only if (i) σ ′ is valid tag corresponding to the forged data block m ′ and the authenticating information w ′ for the targeted user ID u ′ , (ii) Adv2 has not queried for the secret value corresponding to the ID u ′ , and (iii) Adv2 has not queried for the tag for the (m ′ , w ′ , ID u ′ ) tuple at any stage.
It can be noted that we consider only passive attack for a compromised KGC as providing security against active attacks launched by a compromised certificate authority (CA) in a traditional public key infrastructure (PKI)-based protocol is also equally difficult. So, a malicious-but-passive KGC, in this attacker model, may try to forge a tag for a user but without trying to replace the user's public key. us, security against type-II attacker establishes the same level of confidence on a KGC-based CLPKC system as that of a traditional CA-based PKI system.

Type-III Adversary (Adv3).
In type-III attack, we consider a compromised CSP as the possible attacker. However, unlike type-I attack, where the objective of the attacker is to generate tag for a forged data block, in type-III attack, the attacker's objective is to generate a valid data possession proof for a given random challenge without storing all the data blocks of the corresponding data file properly. Like type-I and type-II attacks, we assume that the adversary in this case also has access to all the public parameters used in the protocol including the valid public keys of all genuine users. Since type-III attacker is a compromised CSP, we need to assume that the adversary has got access to all the valid tags corresponding to all the data blocks of the challenged data file. It has also access to all the data blocks of the file only except one of the challenged blocks which, we assume, has been deleted or modified by the attacker.
Game-3, defined below, between a challenger (C) and an adversary Adv3, models the hypothetical type-III attacker discussed above. e game consists of the following phases.
Setup. e challenger C runs the setup algorithm of the CLS-RDIC scheme to obtain the master secret key msk and public parameters params. In addition, C generates a random data file with n number of data blocks and file-id ID F . e challenger forwards only the params to Adv3 and keeps with itself msk and the data file.
Queries. In this phase, Adv3 can make the following queries adaptively to the challenger C.
(i) Hash Query: this query is same as the hash query in game-1. (ii) Data-Block Query: Adv3 can query for any block index i of the data file ID F . Challenger C retrieves corresponding data block from the data file and forwards it to Adv3. (iii) Public-Key Query: same as the Public-Key query defined in game-1. (iv) Tag-Gen Query: Adv3 can submit any block index i of the data file ID F to C. Challenger C runs the Tag-Gen algorithm of the CLS-RDIC scheme to generate the corresponding tag σ i and sends it back to Adv3.
Challenge. C runs the Challenge algorithm of the CLS-RDIC scheme to generate a challenge vector chal for data file ID F and forwards chal to Adv3.
Forge-Proof. Adv3 outputs a data possession proof P corresponding to the given challenge chal. Adv3 wins the game-3 only if (i) P is valid data possession proof corresponding to the given challenge chal and (ii) at least one of the challenged blocks does not appear in any Data-Block query from Adv3.

Cryptanalysis of Existing Schemes
In this section, we perform a detailed cryptanalysis of the CLPKC-based privacy-preserving shared data auditing protocols proposed in [23,39]. Specifically, we analyze the tag unforgeability of these schemes against type-I and type-II attackers as defined in Sections 3.7.1 and 3.7.2. Since the tag-generation mechanisms used in these two protocols are very similar, we mainly discuss the vulnerabilities for one of these schemes [23] and highlight the similarities of the other scheme [39] with [23]. In the following, we first provide a brief description of the tag-generation mechanism used in the protocol [23] and then perform its cryptanalysis. [23].

Brief Description of Jaya et al.'s Scheme
e algorithms involved in the tag generation of the protocol proposed by Jaya et al. [23] are described as follows. e notations used in describing these algorithms are little bit different from the notations used in [23]. We use the notations same as the notations that we use in our proposed protocol description, so that they can be compared easily.
Setup. e KGC runs the setup algorithm and performs the following steps: (1) Selects q, g, G 1 , G 2 , e as described in our Preliminaries section. (2) Chooses a master secret key α ∈ Z * q at random and sets the KGC's public key P pub � g α . e KGC also chooses another random value c o ∈ Z * q and sends it confidentially to the group manager (GM).
Join. Any user entity U j , for 1 ≤ j ≤ d, which is part of network and wants to join a group, requests the GM. e GM after reviewing the request generates a group key δ U j for the user where δ U j � g c o · H 1 (ID U j ) c o and sends δ U j to the corresponding user through a secure channel.
PartialPvtKeyGen. Once the user receives the group key from the GM, the user requests the KGC for the partial private key and sends (ID U j , δ U j ) as part of the request. e KGC validates both (ID U j , δ U j ) as per the verification equation below: (1) If invalid, KGC aborts, else generates Q U j � H 1 (ID U j ) and D U j � Q α U j where ID U j is the unique public identity and D U j is the partial private key of the user U j . KGC forwards D U j to the corresponding user U j via a secure channel.

Security and Communication Networks
SetSecretValue. User U j chooses the values β U j ∈ Z * q and g 1 ∈ G 1 at random and stores with itself β U j as a secret. e user computes ζ � g β U j 1 and makes it public.
SetPublicKey. User U j computes its public key as SignGen. User U j generates tag for a block m i of the file M � 〈m 1 , m 2 , . . . , m n 〉 with file identity F id , where n is the number of blocks, m i ∈ Z q * .
(1) e group user U j computes the tag σ i as (2) e group user U j uploads its message block along with authenticating information and the generated tag (m i , w i , σ i ) to the cloud.
A correctly generated tag σ i satisfies the following equation, which can be verified by the cloud after receiving the tag. (2)

Type-I Attack Analysis
. Suppose a type-I attacker targets user U j as the victim user. According to the definition provided in Section 3.7.1, we can assume that type-I attacker has access to (1) all the public parameters used in the protocol, (2) the public key PK U j of the victim user, and (3) a valid tuple (m i , w i , σ i ) for the i ′ th block of the data file of user U j , for some i. Having these kinds of information, the attacker can execute the following steps to generate a forged tag σ i ′ for a forged data block m i ′ , keeping the authenticating information same as w i and replacing the original public key PK U j of the victim user by a forged public key PK U j ′ .
(1) Generates a forged data block m i ′ of its choice.
It replaces the original public key PK U j of the victim user by the forged public Note that the attacker does not need access to the partialprivate key D U j or the personal secret key β U j of the target user U j .

Lemma 1.
e forged tag σ i ′ generated using the above mechanism is a valid tag on the forged data block m i ′ with authenticating information w i under the public values (ID U j , PK U j ′ ) of the victim user U j .
Proof. In order to prove the lemma, it is sufficient to show that the tuple (m i ′ , w i , σ i ′ ) satisfies the correctness equation as shown in equation (2) under the replaced public key PK U j ′ of user ID U j . e correctness proof is given below: □

Type-II Attack Analysis.
Like type-I attack, a type-II attacker also has the access to all public parameters, including the public key PK U j of the victim user U j , and a valid tuple (m i , w i , σ i ) for some i. In addition, it has the master secret key α in its possession. e attacker can execute the following steps to generate a forged tag σ i ′ for a forged data block m i ′ , keeping the authenticating information same as w i .
(1) Generates a forged data block m i ′ of its choice.
Note that in the above attack, the attacker does not need access to the personal secret key β U j of the victim user U j . Also, it does not replace the original public key PK U j of the user.

Lemma 2.
e forged tag σ i ′ generated using the above mechanism is a valid tag on the forged data block m i ′ with authenticating information w i under the public values Proof. Let us prove the lemma by showing the validity of the forged tuple (m i ′ , w i , σ i ′ ) under the public key PK U j of user U j , as per equation (2). e correctness proof is given below: and hence Remarks on the Analysis. e above analysis shows that if an attacker (type I or type II) obtains a valid data block and tag pair (m i , σ i ) corresponding to some block i of a data file F id belonging to a victim user U j , then it can replace the block by generating a valid tag σ i ′ for a forged block m i ′ while keeping the authenticating information same as w i � F id ‖n‖i. More importantly, we can also observe that the forged block m i ′ can be generated as per the choice of the attacker. Hence, the tag-generation mechanism used in [23] is susceptible to selective forgery attack under both type-I and type-II attackers. It can be noted that a selective forgery attack is more powerful than an existential forgery attack and can become detrimental in a cyber-physical system (CPS) environment where the truthfulness of data is directly associated with safety and security of property and life.
An obvious solution to prevent the above attack could be to prevent an unauthorized entity in obtaining access to a data block and its tag pair. It can be noted that in an RDIC protocol, the metadata (tags) generated by an user are required only by the CSP. Hence, we can keep both data and tag blocks of a file confidential between the user and the CSP only. is simple solution can certainly strengthen the security by completely eliminating type-II attack (compromised KGC) and eliminating type-I attack by any internal/ external entity except the CSP. A compromised CSP can still launch type-I attack since it has access to the valid tag blocks generated by an user and we cannot hide those from the CSP since those are mandatory in calculating data-possession proof during data auditing. Our observation reveals the fact that type-I tag forgery attack is possible against Jaya et al.'s scheme [23] since the tag generation algorithm (SignGen) does not link the authenticating information w i of a block with the public key of the user. is enables a type-I attacker to easily replace the public key and forge a tag for a chosen message as we have shown in our analysis. In our protocol, we utilize the above conclusions to design a novel taggeneration mechanism which is provably secure against both type-I and type-II attacks. [39]. In the following, we briefly describe the tag generation algorithm used in [39]. Again, we keep the notations consistent to the notations used in our proposed protocol.

Brief Overview on the Tag-Generation Mechanism of the Scheme in
Tag-Gen. Using this algorithm, a group user U j for 1 ≤ j ≤ d generates tag for a block m i of the file M � 〈m 1 , m 2 , . . . , m n 〉 with file identity F id where n is the number of blocks, m i ∈ Z q * . User U j computes the tag σ i as where w i � i‖F id . e partial private key is calculated as q 〉 are secretly kept with the group manager, which acts as the KGC in this protocol. User U j sends the message block and tag pair (m i , σ i ) to the cloud and updates a public log file with the values index i, the user public identity H 1 (ID U j + η), and the user public key P U j � g β U j where β U j is secret to the user U j .
It can be noted that the tag generation algorithm discussed above is quite similar to that used in [23] in the sense that in this algorithm, the authenticating information for a block does not contain the information regarding the public key of the user. In addition, the protocol in [39] also does not include any mechanism to hide the valid tags generated by an user from the group manager, acting as the KGC in this protocol. Hence, type-I and type-II attacks can be launched in the same ways as we have shown in Sections 4.2.1 and 4.2.2.

Proposed System Model
In this section, the entities involved, data structures and files used, and the assumptions underlying our proposed protocols are stated in detail.

Entities Involved.
e proposed protocols consist of the following entities. e CSP. In cloud computing, a CSP is responsible for providing the computing and storage facilities to its users. For a FOG-CPS, we assume that the storage is implemented inside the FOG network at the physical proximity of the CPS system [71]. In our protocol, we view the storage facility implemented inside the FOG systems as a local storage server, and without loss of generality, we refer to it as the CSP.

Security and Communication Networks
e Cloud User Group. e cloud user is an edge device in our scheme. A group of edge devices forming a cluster constitutes a user group. ere exists a group manager who manages the usual activities of a user group [72]. ese users contribute data blocks to commonly shared files kept inside the local CSP. During registration of each cloud user, the user establishes a shared secret key with the CSP for confidential communication with it.
e Data Auditor. Unlike the existing RDIC approaches, which use an external fully trusted third-party auditor (TPA), in our protocol, one of the edge devices in a user group would act as the data auditor. Selection of the auditor can be done by the group manager or it can be elected by the group members using some leader election mechanism such as that in [73]. While selecting/electing the auditor, load balancing should be a criterion to be considered. Without loss of generality, throughout the rest of the paper, we assume that there exists a dedicated edge device in a user group acting as the data auditor. Since an edge device is easier to compromise, we assume that the auditor is a semi-trusted entity.
Audit-Verifier. Any edge device belonging to the user group sharing the data file F can act as an audit-verifier to check whether the data auditor is performing its assigned duties correctly or not. We recommend that each edge device invoke this algorithm occasionally so that the load of verification is distributed among all edge devices in the group. Alternatively, the group manager can also prepare a schedule to distribute the verification duty among the group members.
e KGC. It acts as the security server that publishes the public parameter list and grants security credentials to all of the participating entities in the protocol.

Data Structures and Files.
e data structures and files used and maintained by different entities in our protocol are listed below.
Data File. A shared data file F with identity ID F , stored with the CSP and shared among d users (edge devices), can have n number of data blocks 〈m 1 , m 2 , . . . , m n 〉 at any instant in time. Each of these data blocks may be contributed by any one of the d users of that group.
Metadata File. For each data file F, the CSP maintains a metadata file/tag file which contains the tags 〈S 1 , S 2 , . . . , S n 〉 associated with each data blocks of the data file generated by the corresponding users.
Indicator Matrix. For each such data file F, the CSP maintains an indicator matrix I. e indicator matrix is a (n × d) 2D matrix whose each row corresponds to a block index i(1 ≤ i ≤ n) and each column corresponds to an user u(1 ≤ u ≤ d). We use the notation I i,u to denote I[i] [u] which is defined as follows: Log-File-1. e data auditor maintains the Log-File-1. Corresponding to every data audit instance, there is an entry in this file. e fields contained in each entry are as shown below: where t and t ′ indicate the time instances when the audit was invoked and when the corresponding record was inserted into the public blockchain (explained later), respectively, for the file identified by ID F . Result is an 1 bit field indicating whether the CSP passed the specific audit instance or not. A copy of the proof of data possession digitally signed and sent by the CSP, in response to the audit instance, is kept in the last field of the entry. All the cloud users have read access to Log-File-1.
Log-File-2. e CSP maintains Log-File-2 which contains the indicator matrix I for every data file. e auditor and all the cloud users have read access to Log-File-2.

Assumptions.
We assume the existence of a scalable public blockchain, suited for FOG-CPS environments, inside the network. ere are several works that have proposed scalable public blockchain techniques for FOG-CPSs [55][56][57][58] as discussed in Section 2.1. FOG nodes with moderate storage and computing power store the complete blockchain information, and some edge devices with low storage and computing power only maintain a copy of the header information of the blocks in the blockchain. A service-level agreement (SLA) is executed between the group manager, on behalf of a cloud user-group, and the data auditor which determines the frequency of audits or their specific time instants. e auditor is supposed to invoke data auditing protocol as per the requirements specified in the SLA.

Proposed Basic CLS-RDIC Protocol
In this section, we propose a basic CLS-RDIC group shared data auditing protocol applicable for the system model we described in the previous section. Usually, in the existing CLS-RDIC schemes, the data auditor generates the random challenge values used during a data auditing instance by itself. In our protocol, we restrict the auditor to use only time-varying verifiable source of randomness. For this purpose, the data auditor is required to retrieve the latest hash-block from the public blockchain available inside the network. It can be noted that given a time instant t, the latest hash-block is identified uniquely in the blockchain. is mechanism ensures that the auditor cannot send the challenge values in advance to the CSP even when they collude. We have proposed a novel tag generation and tag uploading mechanism which is provably secure against both type-I and type-II attacks. Besides, the data auditing mechanism of the proposed basic CLS-RDIC scheme is also provably secure against type-III attack. However, we do not consider the data privacy requirement and the reliability of auditing service requirement against a compromised data auditor. In other words, the proposed basic CLS-RDIC protocol assumes the data auditor as fully trusted like many of the existing schemes. In the complete version of our protocol, which is proposed in the next section, we relax this assumption and provide additional mechanisms to ensure the security requirements against a semi-trusted auditor. e proposed basic CLS-RDIC shared data auditing protocol consists of a total of nine algorithms, namely, Setup, Partial-Private-Key-Extract, Set-Secret-Value, Private-Key-Gen, Set-Public-Key, Tag-Gen, Challenge, Proof-Gen, and Proof-Ver. Detailed descriptions of each of these algorithms are provided below.
Setup. is algorithm is executed by the KGC during the setup phase of the protocol. Steps of the algorithm are as follows.
(1) On input k, the algorithm generates two cyclic multiplicative groups G 1 , G 2 of prime order q and an admissible bilinear map e: G 1 × G 1 ⟶ G 2 . KGC selects a random generator g ∈ G 1 . (2) KGC chooses a random α ∈ Z * q as the master-secretkey (msk) and sets P pub � g α .
(3) KGC selects three secure hash functions for partialprivate-key and tag generation purposes, respectively, and H 3 : G 2 ⟶ Z * q for masking of data possession proof. e security analysis for the proposed scheme views H 1 and H 2 as random oracles. (4) KGC selects another global hash function defined as Ω: 0, 1 { } * ⟶ 0, 1 { } 2l . e function produces a 2l-bit binary string from a given hash-block of a blockchain. e bit string is further segregated into two l-bit strings, used as the seeds in two pseudorandom functions defined below. (5) Two pseudorandom generation functions are chosen by the KGC as per the following definitions: { } . e first input in both of the above two functions is an l-bit string which is used as a seed to initialize the random number generators. Both of these functions are used for generating the random challenge vectors. (6) e KGC publishes the public parameters params � 〈G 1 , G 2 , q, e, g, P pub , H 1 , H 2 , Ω, f, π〉.
Partial-Private-Key-Extract. On receiving a request from user with identity ID u , KGC calculates Q u � H 1 (ID u ) and D u � Q u α and forwards the partial-private-key D u to the corresponding user through a secure channel.
Set-Secret-Value. User with identity ID u randomly chooses β u ∈ Z * q and keeps it as a personal secret value.
Private-Key-Gen. User with identity ID u sets the private key for itself as 〈D u , β u 〉.
Set-Public-Key. User with identity ID u sets its public key as P u � g β u . e user announces its public key to all the participating entities in the network. It can be noted that because of the use of CLPKC, there is no need for any certificate to be attached with the public key.
Tag-Gen. e steps followed by an user u to generate the encrypted tag-signature T i on data block m i of a data file F are as shown below: (1) Calculates the authenticating tag information w i � (ID F ‖i‖P u ) for the block m i . (2) Computes the tag-signature S i for block m i as e CSP extracts the tag-signature S i by decrypting T i using the shared secret key K u . It calculates the authenticating tag information w i � (ID F ‖i‖P u ) and Q u � H 1 (ID u ) and verifies the tag-signature by checking the following equality: Upon successful verification, the CSP updates the indicator matrix I corresponding to the data file F as I i,u � 1. It also stores the data block m i as the i ′ th block in the data file F and the tag S i as the i ′ th tag value in the corresponding tag file.
Challenge. In order to audit the data file F, the auditor chooses a number c(1 ≤ c ≤ n) as the size of the challenge vector and sends the challenge request as chal � 〈t, c, ID F 〉 to the CSP, where t is the instant in time when the audit gets performed.
Proof-Gen. Upon receiving the challenge from the auditor, the CSP first retrieves the hash-block corresponding to the given instant t from the public blockchain and extracts the two random values k 1 , k 2 ∈ 0, 1 { } l from the retrieved hashblock using the global function Ω. e CSP computes the set (k 1 , x) and v i � f(k 2 , x) for 1 ≤ x ≤ c. Next, it computes proof of possession for the challenged blocks as follows.
Proof-Ver. e auditor verifies the received proof in the following way: (1) e auditor first verifies the signature Sig CSP (P) against the public key of the CSP using the certificateless signature verification mechanism. It proceeds only if the verification is successful. (2) Next, the auditor retrieves the hash-block corresponding to time t from the public blockchain. e retrieved hash-block is used to extract the random values k 1 , k 2 ∈ 0, 1 { } l using the global function Ω.  x) and v i � f(k 2 , x) for all 1 ≤ x ≤ c. (5) For each i ∈ C, the auditor retrieves the public key information for user u such that I i,u � 1 and calculates the authenticating tag information w i � ID F ‖i‖P u . (6) Auditor accepts the proof as valid only if the following equality holds: Once the verification of the received proof P is done, the data auditor creates a report-message of the form Report � 〈t, ID F , Result, Signed Proof〉 where t is the instant of time used in the challenge message, ID F is the identity of the file audited, Result � 1 if the verification resulted in a success, 0 otherwise, and the Signed Proof field contains P, Sig CSP (P).
e auditor submits the hash digest of the Report message along with its identity to the public blockchain. e blockchain verifies the authenticity of the sender and includes the sent digest value along with its sender's identity in the next generated hash-block in the blockchain. Finally, the auditor inserts an entry 〈t, t ′ , ID F , Result, Signed Proof〉 in Log-File-1 where the values of t, ID F , Result, and Signed Proof are exactly the same as those in the Report message. Value of t ′ is the time instant when the hash-block containing the digest of the Report message is inserted in the public blockchain.

Lemma 3.
An honest CSP will always pass the data auditing test as described above.
Proof. In order to prove this lemma, it is sufficient to show that equation (14) always holds true if all values are entered correctly. e correctness proof is given below.
(from equation (10)) Hence, Soundness of the proposed basic CLS-RDIC protocol against type-I, type-II, and type-III attackers has been proved later in the security analysis section.

The Proposed Complete Protocol
In this section, we propose the complete version of our protocol which is an extension over the basic CLS-RDIC protocol we proposed in the previous section. e security credential generation and the tag-generation mechanisms of the complete version are exactly the same as those in the basic version. In addition, like the basic version, in the complete version, we restrict the data auditor to use public blockchain as a time-varying verifiable source of randomness for challenge generation purpose. However, unlike the basic version, in the complete version of our protocol, we consider the data auditor as a semi-trusted entity, applicable for a FOG-CPS environment we described earlier. Hence, we need to protect data confidentiality and ensure the correctness and the timeliness of the auditing service provided by such semi-trusted data auditor. In the following, we first describe the additional attack types that we introduce for such a semi-trusted data auditor and then provide the construction of our proposed certificateless reliable privacypreserving auditing (CRPPA) protocol for shared data auditing in FOG-CPSs.

Security Model for the Complete Scheme.
Type-I, type-II, and type-III attackers are also applicable for the complete version of the proposed protocol. In addition, we define the following types of adversaries to capture a semi-trusted data auditor scenario.

Type-IV Adversary (Adv4).
In type-IV attack scenario, we consider a compromised data auditor as a passive attacker that can try to extract the content of a data file from a number of challenge-response interactions with the CSP while auditing the file. A privacy-preserving RDIC scheme must be able to provide data privacy against a curious auditor. e RDIC protocol needs to incorporate mechanisms to mask the values computed from the data blocks and corresponding tag blocks of the files by the CSP, so that the auditor learns zero information regarding any data block or tag block of the file from the responses received from the CSP. is should be ensured even when the number of such interactions is very large.
is security requirement is analogous to the requirement in a zero-knowledge authentication protocol, such as that in [49,74], where a claimant needs to prove the possession of a secret value without disclosing any information regarding the secret to the verifier.

Type-V Adversary (Adv5).
Security of an RDIC protocol against a type-III attacker (Section 3.7.3) provides the assurance that a compromised CSP cannot generate a valid data possession proof for a given random challenge without storing all the data blocks of the corresponding data file properly. is assurance is valid under the assumption that the data auditor is honest and it performs its assigned tasks correctly. In type-V attack, we consider the possible collusion between a compromised data auditor and the CSP. e objective of the attack is same as that in type-III attack, i.e., to hide intentional/unintentional deletion or modifications of data blocks of a data file from its users. e compromised data auditor can achieve this objective in two possible ways. Simplest way is to generate false audit reports whenever the CSP fails to provide valid data possession proofs. Alternatively, the compromised auditor can disclose the random challenge vectors in advance to the CSP, using which, the CSP can precalculate data possession proofs and then delete or modify data blocks of a data file. Security of an RDIC scheme against type-V attacker requires mechanisms to detect a compromised auditor when it generates incorrect audit report and to prevent it from disclosing the random challenges in advance to anybody.

Type-VI Adversary (Adv6).
In type-VI attack, the adversary is a compromised selfish data auditor, where the objective of the attacker is to save its computational resources. In this attack, the compromised selfish auditor may deviate from the SLA by skipping or delaying the auditing duties. An RDIC protocol, secure against type-VI attacker, must be able to verify timeliness of the data auditing tasks performed by a data auditor.
Our proposed scheme has considered six attack scenarios where an edge device (user) is a victim. Type-I and type-II adversaries arise from the security vulnerabilities of the key distribution mechanism of the CLPKC. In type-I attack, the compromised user tries to perform a tag forgery to impersonate a legitimate user, and the attack may be launched by replacing the public key of the legitimate user. In type-II attack, the compromised but passive KGC performs a tag forgery to impersonate a legitimate user. However, the KGC is trusted not to replace the legitimate user's public key. In type-III attack, a compromised CSP generates a forgery on the data possession proof to suppress a data loss or data corruption event. Security against type-III is a mandatory requirement of an RDIC scheme. In type-IV attack, a compromised data auditor performs cryptanalysis on the challenge-response messages to extract the users' confidential data or metadata. A public RDIC scheme must protect user data against type-IV attacks. In a type-V attack, the data auditor reveals the random challenge vectors in advance to the CSP to help CSP precompute the integrity proofs so that CSP can suppress a data loss or data corruption event in the future. In type-VI attack, the compromised data auditor skips or delays an auditing task to save computational resources. Table 2 summarizes the six types of attack scenarios, the entities involved in the attack, the objective of the attack, and the method of attack.

Construction of the Proposed CRPPA Protocol.
e proposed certificateless reliable privacy-preserving auditing (CRPPA) protocol for shared data auditing in FOG-CPSs consists of a total of ten algorithms. e Setup, Partial-Private-Key-Extract, Set-Secret-Value, Private-Key-Gen, Public-Key-Gen, Tag-Gen, and Challenge algorithms of the CRPPA protocol are exactly the same as those in our proposed basic CLS-RDIC scheme. However, in the Proof-Gen algorithm, we use proper masking techniques to ensure that no information regarding either the data blocks or the tags is leaked to the auditor even if it executes millions of challenge verification instances with the CSP. e Proof-Ver algorithm has been modified accordingly. Additionally, we introduce the Verify-Proof algorithm which can be used by an audit-verifier to occasionally verify the activities of the auditor.
e Proof-Gen, Proof-Ver, and the Verify-Proof algorithms of the proposed CRPPA protocol are explained below.
Proof-Gen. Upon receiving the challenge from the auditor, the CSP retrieves the random values k 1 , k 2 using the global function Ω from the public blockchain as described in the proposed basic CLS-RDIC scheme. e CSP computes proof of possession for the challenged blocks as follows.
e CSP sets C �

Security and Communication Networks 15
For each user u ∈ 1, . . . , d { }, (1) e CSP computes the public value Q u � H 1 (ID u ) and selects three random values r m u ← R Z * q , r σ u ← R Z * q , ρ u ← R Z * q , which are used for masking the σ and μ values.
Proof-Ver. e auditor first checks if Sig CSP (P) is a valid signature on proof P � 〈μ ′ , Σ, ε, R〉 using the public key of the CSP and then executes the following steps to verify the proof P: (1) e auditor retrieves the hash-block corresponding to time t from the public blockchain. e retrieved hash-block is used to extract the random values k 1 , k 2 ∈ 0, 1 { } l using the global function Ω.
For each i ∈ C, the auditor gets public key information of user u such that I i,u � 1 and calculates the authenticating tag information w i � ID F ‖i‖P u . (6) e auditor accepts the proof only if the following equation holds correct.
· e μ π ′ , P pub · e g 1 , g ε π . (20) Once the verification of the received proof P is done, the data auditor creates a report-message of the form Report � 〈t, ID F , Result, Signed Proof〉 where t is the instant of time used in the challenge message, ID F is the identity of the file audited, Result � 1 if the verification resulted in a success, 0 otherwise, and the Signed Proof field contains P, Sig CSP (P). e auditor submits the hash digest of the Report message along with its identity to the public blockchain. e blockchain verifies the authenticity of the sender and includes the sent digest value along with its sender's identity in the next generated hash-block in the blockchain. Finally, the auditor inserts an entry 〈t, t ′ , ID F , Result, Signed Proof〉 in Log-File-1 where the values of t, ID F , Result, and Signed Proof are exactly the same as those in the Report message. Value of t ′ is the time instant when the hash-block containing the digest of the Report message is inserted in the public blockchain.

Lemma 4.
An honest CSP will always pass the data auditing test as described in the proposed CRPPA protocol. Proof. In order to prove this lemma, it is sufficient to show that equation (20) always holds true if all values are entered correctly. e correctness proof is given below. Hence, � e μ π ′ , P pub · e g 1 , g Verify-Proof. In order to audit data file F, an audit-verifier first chooses an audit-interval T � [T 1 , T 2 ] from the past and retrieves all the entries from Log-File-1 where the audit instance t lies in the interval T and the ID F field matches the id of file F. Next, it verifies whether the audit instances are as per the SLA or not. If any one of the extracted entries contains a zero value in its Result field, the audit-verifier retrieves the Signed Proof corresponding to that entry and invokes the Proof-Ver algorithm to check whether the data possession proof sent by CSP was valid or not. If it is a valid proof, then it reports to the group manager against the data auditor as misbehaving. If the proof is invalid, it reports to the group manager against the CSP as misbehaving. When all entries contain 1 in the Result fields, the audit-verifier retrieves the signed proofs from all the entries and performs an aggregate proof verification in the following way.
We use the notation Signed Proof(t) to denote the signed proof at audit instance t ∈ T. Hence, Signed Proof (1) For each audit instance t ∈ T, the audit-verifier performs the following: (i) Checks the validity of the signature Sig CSP (P(t)) using the public key of the CSP. It proceeds only if the signature is valid. and where k 1 (t) and k 2 (t) are the random strings extracted using the global function Ω from the hashblocks at time instant t of the public blockchain. (iv) e audit-verifier computes the following aggregates values for the audit instance t: (2) Finally, the audit-verifier computes the following aggregate values by aggregating the above aggregate values for all t ∈ T: (3) For all i ∈ C agg , the verifier retrieves the public key P u of user u such that I i,u � 1 and calculates the authenticating tag information as w i � ID F ‖i‖P u .
□ Lemma 5. If the data auditor performs all the proof verifications honestly for each audit instance t ∈ T, then the abovementioned aggregate audit verification must result in success.
Proof. e above-mentioned aggregate audit verification is initiated only when the Result field in each entry corresponding to each audit instance t ∈ T shows 1, in the Log-File-1. is can happen only when the Proof-Ver algorithm resulted in success for each of the instance t ∈ T, since we assume that the data auditor executed the Proof-Ver algorithm honestly for each of these instances. Hence, each of the instance t ∈ T must satisfy equation (20), i.e., · e μ π ′ (t), P pub · e g 1 , g ε π (t) .

(27)
Let us take the product of the left-hand side (LHS) of the above equation for all t ∈ T: Similarly, we take the product of the right-hand side (RHS) of equation (27) for all t ∈ T:- Equations (28) and (29) directly establish that equation (26) must hold true. Hence, the aggregate verification must result in success.
So, if the above-mentioned aggregate audit verification does not result in success, the audit-verifier reports against the data auditor as misbehaving to the group manager. e above procedure verifies whether the data auditor performs its assigned auditing task correctly or not. In order to check whether all the auditing tasks were performed timely or not, the audit-verifier proceeds as follows.
For each of the audit instance t ∈ T, the audit-verifier constructs a Report message the same way as it is mentioned in the Proof-Ver algorithm, i.e., Report � 〈t, ID F , Result, SignedProof〉. e verifier then retrieves the t ′ field corresponding to the entry from Log-File-1 and checks whether the hash digest of the Report message exists in the hash-block corresponding to time t ′ in the public blockchain or not. If the verification fails for any audit instance t ∈ T, the audit-verifier reports against the timeliness of auditing performed by the data auditor to the group manager.
Soundness of the aggregate verification used in the Verify-Proof algorithm has been analyzed in the next section.

Soundness Proof for the Proposed Basic CLS-RDIC
Scheme. In this subsection, we prove the security of our proposed basic CLS-RDIC scheme against type-I, type-II, and type-III attackers. In Section 8.2, we establish the security of our proposed CRPPA scheme based on the fact that the proposed basic scheme is secure against type-I, type-II, and type-III attackers. In eorems 1 and 2, we analyze the security of the tag-generation mechanism of the basic CLS-RDIC scheme against type-I and type-II attackers as defined in Sections 3.7.1 and 3.7.2, respectively. In eorem 3, we analyze the security of the data auditing challenge-response protocol of the basic CLS-RDIC scheme against type-III attacker as defined in Section 3.7.3. e following theorem proves that, in the random oracle model, the tags generated by the proposed basic CLS-RDIC scheme are unforgeable under an adaptive chosen-message type-I attacker assuming that the CDH problem in G 1 is hard.

Theorem 1. If an adversary Adv1, as defined in game-1, has a success probability of ξ(k) in generating a forged tag against our proposed basic CLS-RDIC scheme, then there exists a challenger C that solves an instance of a CDH
problem in group G 1 . Suppose Adv1 makes at most q 1 H 1 hash queries, q 2 partial-private-key queries, q 3 secret-value queries, q 4 public-key queries, q 5 public-key-replace queries, q 6 H 2 hash queries, and q 7 tag-gen queries, where q 1 , q 2 , q 3 , q 4 , q 5 , q 6 , q 7 all are in polynomial(k); then, the success probability, ξ ′ (k), of challenger C in solving the above problem is lower bounded by where e ≈ 2.71828 is the base of the natural logarithm. In addition, the time complexity Proof. Let Adv1 be the adversary as in game-1 who is capable of forging a tag. en, we construct a simulator C using Adv1 as subroutine to solve the CDH problem in G 1 . C simulates game-1 in the following way.
H 1 Hash Query. Adv1 adaptively queries for H 1 for any identity ID u . For every H 1 query, C maintains a list H 1 -List � (ID u , Q u , r u , S u , P u , b u ) . If the ID u is already queried before, C simply retrieves the tuple from the H 1 -List and returns Q u to Adv1. If ID u is new, C randomly picks r u ∈ Z * q and tosses a coin b u ∈ 0, 1 { }, where the probability of b u � 0 is φ and that of b u � 1 is 1 − φ. If (b u � 0), then C sets Q u � g r u , chooses a random value β u ∈ Z * q , and sets S u � β u and P u � g β u . Else if (b u � 1), then C sets Q u � h 2 · g r u , chooses a random value β u ∈ Z q * , and sets S u � β u and P u � g β u . Finally, C inserts the values (ID u , Q u , r u , S u , P u , b u ) into H 1 -List. Return Q u to Adv1.
Partial-Private-Key Query. Adv1 adaptively queries for partial-private-key for any identity ID u . C scans for ID u in H 1 -List. If ID u does not exist in H 1 -List, C queries itself for H 1 (ID u ). If b u � 0, then retrieve r u from H 1 -List set D u � h r u 1 and return D u to Adv1. Else if b u � 1, then abort.
Secret-Value Query. Adv1 adaptively queries for set-secretvalue for any identity ID u . C scans for ID u in H 1 -List. If ID u does not exist in H 1 -List, C queries itself for H 1 (ID u ). If (S u � ⊥), C chooses a random value β u ∈ Z q * and sets S u � β u and P u � g β u . C updates the values (S u , P u ) into H 1 -List and returns S u to Adv1.
Public-Key Query. Adv1 adaptively queries for public-key for any identity ID u . C scans for ID u in H 1 -List. If ID u does not exist in H 1 -List, C queries itself for H 1 (ID u ). C retrieves P u and returns it to Adv1.
Public-Key-Replace Query. Adv1 adaptively queries for a public-key replacement for any identity ID u with (ID u , P u ′ ). C scans for ID u in H 1 -List. If ID u does not exist in H 1 -List, C queries itself for H 1 (ID u ). C sets S u � ⊥ and P u � P u ′ and updates H 1 -List.
H 2 Hash Query. Adv1 adaptively queries for (w k , P u ). For every H 2 query, C maintains a list H 2 -List � (w k , H 2 k , r k , P u ) . C scans H 2 -List for (w k , P u ). If (w k , P u ) does not exist in H 2 -List, C randomly chooses r k ∈ Z q * , sets H 2 k � g r k , and updates H 2 -List. C returns H 2 k to Adv1.
Forge-Tag. Adv1 outputs a tuple (σ ′ , m ′ , w k ′ , ID u ′ , P u ′ ), where σ ′ is the forged tag on the message m ′ with authenticating information w k ′ for identity ID u ′ with public key P u ′ .
Analysis. If Adv1 successfully forges the tag, then the tuple should be valid. If (b u � 0), then C aborts. Else if (b u � 1), C uses the following verification equation: e(σ ′ , g) � e(H 1 (ID u ′ ) m′ , P pub ) · e(H 2 (w k ′ , P u ′ ), P u ′ ). C retrieves the tuple from H 1 -List for the forged ID u ′ , and C retrieves the value of Q u � h 2 · g r u from H 1 -List and H 2 (w k ′ , P u ′ ) � g r k ′ from H 2 -List. As per the verification equation above, C is able to calculate solution to CDH problem, i.e., given an instance of the CDH problem (g, h 1 � g α , h 2 ), C calculates h α 2 as follows.
As per the verification equation: e σ ′ , g � e h 2 · g r u m , P pub · e g r k ′ , P u ′ , e σ ′ , g � e h 2 α·m′ · g α r u ·m′ , g · e P u ′ r k ′ , g , We now calculate the minimum success probability ξ ′ (k) with which the challenger C can solve an instance of the given CDH problem in G 1 . For this to happen, the challenger C must not abort during the above simulation.
ere are three phases in the simulation where the challenger C can abort, i.e., in partial-private-key query phase, tag-gen query phase, and analysis phase. e partial-private-Security and Communication Networks key query phase and the tag-gen query phase do not abort when b u � 0, whereas the analysis phase does not abort when b u � 1. Hence, the probability that the challenger C does not abort the above simulation is (1 − φ) · φ q 2 +q 7 . e quantity (1 − φ) · φ q 2 +q 7 is maximized when φ � φ max � q 2 + q 7 / 1 + q 2 + q 7 . By substituting the above value of φ max , we get the lower bound on the probability that the challenger C does not abort as 1/e · (1 + q 2 + q 7 ). Hence, the minimum success probability with which the challenger C can solve an instance of the given CDH problem is ξ ′ (k) ≥ ξ(k)/e· (1 + q 2 + q 7 ). It can be noted that since q 2 and q 7 are polynomial(k), the quantity 1/(1 + q 2 + q 7 ) is non-negligible. us, if ξ(k) is non-negligible, then the success probability ξ ′ (k) is also non-negligible. e running time of C is the sum of upper bounded running time of adversary algorithm Adv1 (O (Adv1)) and upper bounded running time of all the algorithms used in simulating the challenger C, i.e., H 1 hash query (t 1 ), partialprivate-key query (t 2 ), secret-value query (t 3 ), public-key query (t 4 ), public-key-replace query (t 5 ), H 2 hash query (t 6 ), and tag-gen query (t 7 ) executed q 1 , q 2 , q 3 , q 4 , q 5 , q 6 , and q 7 times, respectively.
. Now since all the algorithms used in the simulation of . It can be noted that q 1 , q 2 , q 3 , q 4 , q 5 , q 6 , and q 7 all are in polynomial(k). erefore, O(C) ≈ O(Adv1). It can be observed that if Adv1 is a polynomial-time algorithm, then the simulated CDH problem solver C is also a polynomialtime algorithm. e following theorem proves that, in the random oracle model, the tags generated by the proposed basic CLS-RDIC scheme are unforgeable under an adaptive chosen-message type-II attacker assuming that the CDH problem in G 1 is hard. □ Theorem 2. If an adversary Adv2, as defined in game-2, has a success probability of ξ(k) in generating a forged tag against our proposed basic CLS-RDIC scheme, then there exists a challenger C that solves an instance of a CDH problem in group G 1 . Suppose Adv2 makes at most q 1 H 1 hash queries, q 2 secret-value queries, q 3 public-key queries, and q 4 H 2 hash queries, where q 1 , q 2 , q 3 , and q 4 all are in polynomial(k); then, the success probability, ξ ′ (k), of challenger C in solving the above problem is lower bounded by where e ≈ 2.71828 is the base of the natural logarithm. In addition, the time complexity classes are O(C) ≈ O(Adv2) Proof. Let Adv2 be the adversary as in game-2 who is capable of forging a tag. en, we construct an adversary C using Adv2 as subroutine to solve the CDH problem in G 1 . C simulates game-2 in the following way.
H 1 Hash Query. Adv2 adaptively queries for H 1 for any identity ID u . For every H 1 query, C maintains a list H 1 -List � (ID u , Q u , r u , S u , P u ) . If the ID u is already queried before, C simply retrieves the tuple from the H 1 -List and returns Q u to Adv2. If ID u is new, C randomly picks r u , β u ∈ Z * q , sets Q u � g r u , and tosses a coin b u ∈ 0, 1 { }, where the probability of b u � 0 is φ and that of b u � 1 is 1 − φ . If (b u � 0), then C sets P u � g β u and S u � β u . Else if (b u � 1), then C sets P u � (h 1 ) β u and S u � ⊥. Finally, C inserts the values (ID u , Q u , r u , S u , P u ) into H 1 -List. C returns Q u to Adv2.
Secret-Value Query. Adv2 adaptively queries for set-secretvalue for any identity ID u . C scans for ID u in H 1 -List. If ID u does not exist, C queries itself for H 1 (ID u ). If (b u � 1), abort; else, C retrieves S u and returns it to Adv2.
Public-Key Query. Adv2 adaptively queries for public-key for any identity ID u . C scans for ID u in H 1 -List. If ID u does not exist, C queries itself for H 1 (ID u ). C retrieves P u and returns it to Adv2.
H 2 Hash Query. Adv2 adaptively queries for (w k , P u ). For every H 2 query, C maintains a list H 2 -List � (w k , H 2 k , r k , P u ) . C scans H 2 -List for (w k , P u ). If (w k , P u ) does not exist, C randomly chooses r k ∈ Z q * , sets H 2 k � (h 2 ) r k , and updates H 2 -List. C retrieves H 2 k and returns it to Adv2.
Forge-Tag. Adv2 outputs a tuple (σ ′ , m ′ , w k ′ , ID u ′ , P u ′ ), where σ ′ is the forged tag on the message m ′ with authenticating information w k ′ for identity ID u ′ with public key P u ′ .
Analysis. If Adv2 successfully forges the tag, then the tuple should be valid. If (b u � 0), then C aborts. Else if (b u � 1), C uses the following verification equation: e(σ m′ , g) � e(H 1 (ID u ′ ) m′ , P pub ) · e(H 2 (w k ′ , P u ′ ), P u ′ ). C retrieves the tuple from H 1 -List for the forged ID u ′ , and C retrieves the value of Q u � g r u from H 1 -List and H 2 (w k ′ , P u ′ ) � (h 2 ) As per the verification equation: We now calculate the minimum success probability ξ ′ (k) with which the challenger C can solve an instance of the given CDH problem in G 1 . For this to happen, the challenger C must not abort during the above simulation.
ere are two phases in the simulation where the challenger C can abort, i.e., in secret-value query phase and analysis phase. e secret-value query phase does not abort when b u � 0, whereas the analysis phase does not abort when b u � 1. Hence, the probability that the challenger C does not abort the above simulation is (1 − φ) · φ q 2 . e quantity (1 − φ) · φ q 2 is maximized when φ � φ max � q 2 /1 + q 2 . By substituting the above value of φ max , we get the lower bound on the probability that the challenger C does not abort as 1/e · (1 + q 2 ). Hence, the minimum success probability with which the challenger C can solve an instance of the given CDH problem is ξ ′ (k) ≥ ξ(k)/e · (1 + q 2 ). It can be noted that since q 2 is polynomial(k), the quantity 1/(1 + q 2 ) is non-negligible.
us, if ξ(k) is non-negligible, then the success probability ξ ′ (k) is also non-negligible. e running time of C is the sum of upper bounded running time of adversary algorithm Adv2 (O (Adv2)) and upper bounded running time of all the algorithms used in simulating the challenger C, i.e., H 1 hash query (t 1 ), secretvalue query (t 2 ), public-key query (t 3 ), and H 2 hash query (t 4 ) executed q 1 , q 2 , q 3 , and q 4 , times respectively. erefore, . Now since all the algorithms used in the simulation of challenger . It can noted that q 1 , q 2 , q 3 , and q 4 all are in polynomial(k). erefore, It can be observed that if Adv2 is a polynomial-time algorithm, then the simulated CDH problem solver C is also a polynomial-time algorithm. e following theorem proves that, in the random oracle model, the data audit proofs generated by the proposed basic CLS-RDIC scheme are unforgeable by a type-III attacker assuming that the CDH and DL problem in G 1 are hard. □ Theorem 3. If an adversary Adv3, as defined in game-3, has a success probability of ξ(k) in generating a forged data audit proof against our proposed basic CLS-RDIC scheme, then there exists a challenger C that solves an instance of a CDH or DL problem in group G 1 . Suppose Adv3 makes at most q 1 H 1 hash queries, q 2 data-block queries, q 3 public-key queries, and q 4 tag-gen and H 2 queries, where q 1 , q 2 , q 3 , q 4 all are in polynomial(k); then, the success probability, ξ ′ (k), of challenger C in solving the above problem is lower bounded by where q is the order of the group G 1 . In addition, the time complexity Proof. Let Adv3 be the adversary as in game-3 who is capable of generating a valid data possession proof for the challenged blocks. en, we construct a PPT simulator C using Adv3 as subroutine to solve either the DH or the CDH problem in G 1 . C simulates game-3 in the following way.
Setup. Given an instance of CDH problem (g, G 1 , (h 1 � g a ), (h 2 � g b )) and an instance of the DL problem (g, G 1 , (h 2 � g b )). C chooses another cyclic multiplicative group G 2 , where (|G 1 | � |G 2 | � q), and an admissible bilinear map e: G 1 × G 1 ⟶ G 2 , sets the public parameters params � 〈G 1 , G 2 , q, e, g, P pub � h 1 〉, and sends params to Adv3, and a and b are unknown to C. H 1 Hash Query. Adv3 adaptively queries for H 1 for any identity ID u . For every H 1 query, C maintains a list H 1 -List � (ID u , Q u , r u , β u , P u ) . If ID u is already queried before, C simply retrieves the tuple from the H 1 -List and returns Q u to Adv3. If ID u is new, C randomly picks r u , β u ∈ Z * q and sets Q u � g r u h β u 2 and P u � h β u 2 . Finally, it inserts the values (ID u , Q u , r u , β u , P u ) into H 1 -List. C returns Q u to Adv3.

Data-Block Query.
e file F � 〈m 1 , . . . , m n 〉 with file identifier ID F is available with C, for n is the number of blocks in the file. C maintains an indicator matrix I. Adv3 can adaptively query for block index i. en, C retrieves corresponding data block from the date file ID F and forwards to Adv3.
Public-Key Query. Adv3 adaptively queries for the public key of any identity ID u . C scans for ID u in H 1 -List, and if ID u does not exist, C queries itself for H 1 (ID u ). C retrieves P u and returns it to Adv3.
Tag-Gen Query and H 2 Query. C maintains a list H 2 ′ -List � 〈i, b i , H 2 (ID F ‖i‖P u ), σ i 〉 and computes tag for each index in ID F corresponding to user u shown in indicator matrix I as follows.
C randomly picks b i ∈ Z * q , for i ∈ 1, . . . , n. For each where β u and r u are retrieved from H 1 -List corresponding to P u . e validity of the tag simulation can be verified as follows.
Challenge. C chooses a number c (1 ≤ c ≤ n) as the size of the challenge vector and two random values k 1 , k 2 ∈ 0, 1 { } l using the global function Ω, which act as the seeds for the two pseudo-random functions π and f, respectively. C sends the challenge request as chal � 〈c,
Further C computes the following values: Both the proofs P and P ′ should be valid as per the following equality: e σ π ′ , g � e μ π ′ , P pub .
If μ π � μ π ′ , then Adv3 stores the challenged message blocks correctly which contradicts our assumption. So, there are two cases. Hence, the minimum success probability ξ ′ (k) with which the challenger C can solve an instance of the given DL problem in G 1 is ξ ′ (k) ≥ ξ(k) · (1 − 1/q). It can be noted that since q is exponential(k), the quantity (1 − 1/q) is non-negligible. us, if ξ(k) is non-negligible, then the success probability ξ ′ (k) is also non-negligible.
Dividing (26) by (20): C knows σ π , σ π ′ , Δμ u , h 1 , r u , β u , and hence C can compute h a 2 , the solution to the CDH problem. It can be observed that the solution to an instance of CDH problem is found, unless the denominator in the exponent d u�1 β u Δμ u is zero. However, we have already noted that not all of Δμ u can be zero, and the values β u are randomly chosen by the challenger C from Z q * . Hence, the probability that denominator is zero is 1/q. We now calculate the minimum success probability ξ ′ (k) with which the challenger C can solve an instance of the given CDH problem. For this to happen, the denominator in the exponent must be non-zero and its probability is (1/q). Hence, the minimum success probability ξ ′ (k) with which the challenger C can solve an instance of the given CDH problem in G 1 is ξ ′ (k) ≥ ξ(k) · (1 − 1/q). It can be noted that since q is exponential(k), the quantity (1 − 1/q) is nonnegligible. us, if ξ(k) is non-negligible, then the success probability ξ ′ (k) is also non-negligible. e running time of C is the sum of upper bounded running time of adversary algorithm Adv3 (O (Adv3)) and upper bounded running time of all the algorithms used in simulating the challenger C, i.e., H 1 hash query (t 1 ), datablock query (t 2 ), public-key query (t 3 ), and tag-gen and H 2 query (t 4 ) executed q 1 , q 2 , q 3 , and q 4 times, respectively. erefore, . Now since all the algorithms used in the simulation of challenger C are polynomial-time computable, O(C) � O(Adv3) + O(q 1 + q 2 + q 3 + q 4 ). It can noted that q 1 , q 2 , q 3 , and q 4 all are in polynomial(k). erefore, O(C) ≈ O(Adv3). It can be observed that if Adv3 is a polynomial-time algorithm, then the simulated DL or CDH problem solver C is also a polynomial-time algorithm.

Soundness Proof for the Proposed CRPPA Scheme.
e proposed CRPPA scheme uses the same tag-generation mechanism of that of our proposed basic CLS-RDIC scheme. Hence, the security proofs for tag-unforgeability will be same as eorems 1 and 2 against type-I and type-II attackers, respectively. Since the proposed CRPPA scheme employs zero-knowledge mechanisms to establish privacypreserving data possession proof, we provide both the soundness and the zero-knowledge privacy proofs to establish the security of the privacy-preserving data auditing mechanism against type-III and type-IV adversaries, respectively. eorem 2 bases on eorem 1 to establish the soundness of the privacy-preserving mechanism used in the CRPPA scheme against type-III attacker. eorem 5 establishes the zero-knowledge data privacy proof against type-IV attacker. Finally, the soundness property of the Verify-Proof algorithm of the proposed CRPPA scheme is established in eorem 4. e following theorem proves that, in the random oracle model, the tags generated by the proposed CRPPA scheme are unforgeable by a type-III attacker assuming the unforgeability of the data audit proof of the proposed basic CLS-RDIC scheme.

Theorem 4.
If an adversary Adv3 has a success probability of ξ(k) in generating a forged data audit proof against our proposed CRPPA scheme, then there exists a challenger C that generates a forged data audit proof against the proposed basic CLS-RDIC scheme. Suppose Adv3 makes at most q 1 H 3 hash queries and q 2 data-block and tag-gen queries, where q 1 , q 2 both are in polynomial(k), and Pr[frk] denotes the forking probability as per forking lemma [67]. en, the success probability, ξ ′ (k), of challenger C in solving the above problem is lower bounded by where q is the size of the co-domain (Z q * ) of H 3 hash function. In addition, the time complexity classes are Proof. Let Adv3 be the adversary as in game-3 who is capable of generating a valid data possession proof against the proposed CRPPA scheme for a given random challenge chal without having at least one of the challenged blocks in its possession. en, we show that we can construct a PPT simulator C using Adv3 as subroutine to forge the data possession proof for the proposed basic CLS-RDIC scheme for the same challenge chal. It can be noted here that the simulator C acts as a challenger for type-III adversary against the CRPPA scheme and acts as type-III adversary against the proposed basic CLS-RDIC scheme at the same time. We use the forking theorem introduced by Bellare and Neven in [67] to establish our proof.
Given the public parameters params � 〈G 1 , G 2 , q, e, g, P pub 〉 and instance of the challenge set chal � 〈c, k 1 , k 2 , ID F 〉, C segregates the challenge chal into d subsets, for each subset belongs to a unique user. C simulates game-3 in the following way.
H 3 Hash Query. Adv3 queries for H 3 for any value R ∈ G 2 . For each H 3 query, C maintains a H 3 -List � (R, c) . If R is already queried, C retrieves the tuple from the H 3 -List and returns c to Adv3. If R is new, C randomly chooses a c ∈ Z q * and sends c to Adv3 as response.

Data-Block and Tag-Gen Queries.
Since the simulator C is acting as a type-III adversary against the proposed basic CLS-RDIC scheme, it is also entertained for Data-Block and Tag-Gen queries, as defined in game-3. e Data-Block and Tag-Gen queries received by C from Adv3 are entertained by it by utilizing its own privileged in this regard.
Challenge. C forwards the challenge set corresponding to a user as chal u � 〈c u , k 1 , k 2 , ID F 〉 to Adv3.
Forge-Proof. Adv3 outputs privacy-preserving integrity proof P 1u � 〈μ 1u ′ , Σ u , ε 1u , R u 〉. e value R u must have been queried to the hash oracle where H 3 (R u ) � c 1u . Since the output of H 3 hash oracle is uniformly random in Z q * , the adversary Adv3 cannot obtain H 3 (R u ) without querying H 3 . However, H 3 (R u ) is essential in generating a valid proof P 1u . Hence, the value of c 1u must have been queried.
C uses the forking technique to rewind the simulation to the instance where the value R u is queried to the hash oracle. C replies c 2u as the hash value of R u . Finally, Adv3 outputs privacy-preserving integrity proof P 2u � 〈μ 2u ′ , Σ u , ε 2u , R u 〉.
Since both proofs P 1u and P 2u are valid proofs, they must satisfy auditor verification equation (20): Dividing (14) by (10), we get Taking root of (c 2u − c 1u ) on both sides: Substituting the value of Σ u , μ u , ρ u , we get which is nothing but the auditor verification equation for the user u, and the values (σ u , μ u ) correspond to the integrity proof of our proposed basic CLS-RDIC scheme.
Repeating the above simulation for all the users, we finally output the integrity proof corresponding to the challenge chal for the proposed basic CLS-RDIC scheme, which is a set of σ u , μ u for all u in chal.
We now calculate the minimum success probability ξ ′ (k) with which the challenger C can generate a forged data audit proof against the basic CLS-RDIC scheme. For this to happen, the challenger C must not abort during the above simulation.
e challenger aborts only when forking is unsuccessful. So, let us calculate the success probability of forking as discussed in Section 3.2. Here in this simulation, the random oracle RO is the hash function H 3 . We respond to a total of q 1 number of RO queries received from the adversary Adv3. For each of these queries, we return a random value from the co-domain Z q * . e output 24 Security and Communication Networks generated by the adversary algorithm Adv3 is the proof P 1u which contains a component R u . As stated earlier, R u must have been queried to the hash oracle H 3 . Hence, the acceptance probability of the adversary algorithm Adv3 is Pr[acc] � 1. us, applying the forking lemma as stated in Section 3.2, the forking success probability Pr[frk] ≥ (1/q 1 − 1/|Z q * |) � (1/q 1 − 1/q). Hence, the minimum success probability with which the challenger C can generate a forged data audit proof against the basic CLS- It can be noted that Pr[frk] is non-negligible, since q 1 is in polynomial(k) and q is in exponential(k). us, if ξ(k) is non-negligible, then the success probability ξ ′ (k) is also non-negligible. e running time of C is the sum of upper bounded running time of adversary algorithm Adv3 (O (Adv3)) and upper bounded running time of all the algorithms used in simulating the challenger C, i.e., H 3 hash query (t 1 ) and datablock and tag-gen queries (t 2 ) executed q 1 and q 2 times, respectively. erefore, . Now since all the algorithms used in the simulation of challenger C are polynomial-time computable, . It can be noted that q 1 and q 2 both are in polynomial(k). erefore, O(C) ≈ O(Adv3). It can be observed that if Adv3 is a polynomial-time algorithm, then the simulated data audit proof forger C against basic CLS-RDIC scheme is also a polynomial-time algorithm. □ Theorem 5.
e proposed CRPPA protocol is secure against type-IV attacker, in the random oracle model. Suppose Adv4 makes at most q 1 H 1 hash queries, where q 1 is in polynomial(k). en, the success probability that the simulator S can generate a valid data possession proof corresponding to a given challenge is where q is the order of the group Z q * . In addition, the time complexity classes are O(C) ≈ O(q 1 ).
Proof. We prove the above theorem by showing that it is possible to design a simulator S that can generate a valid data possession proof corresponding to any given challenge chal without any knowledge about the data and tag blocks, if it has control over the random oracle hash function H 3 used in the masking technique of CRPPA. We show the success probability of such simulation to be non-negligible.
Setup. e simulator S receives a random tape and public parameters params. H 3 Hash Query. In order to simulate H 3 hash function as a random oracle, S maintains a H 3 -List � (R, c) . If R is already queried, S retrieves the tuple from the H 3 -List and returns c as the response. If R is new, S randomly chooses a c ∈ Z q * and returns c as the response.
Challenge. S receives the challenge set corresponding to a user ID u as chal � 〈c, k 1 , k 2 , ID F , ID u 〉.
Forge-Proof. After receiving the challenge chal � 〈c, k 1 , k 2 , ID F , ID u 〉, S computes the forged proof P using the following steps: (6) If R already exists in the H 3 -List, then abort the simulation. (7) Else, set H 3 (R)←c. e simulator S returns proof P � 〈μ ′ , Σ, ε, R〉. It is easy to check that P is a valid data integrity proof corresponding to the given challenge chal.

Success
Probability. e success probability of this simula- where P(F) � the probability with which simulator S aborts. e simulation aborts only in step 6, when the value of R computed in step 5 already exists in H 3 -List.
Let polynomial number (q l ) of H 3 queries be received by the simulator S during the simulation. e probability that the value R computed in step 5 matches with any one of the previously queried H 3 queries is proportional to q l /q, where q is the order of the group Z q * . e value q l /q is an inverse exponential function of k, and thus ξ ′ (k) ≈ 1 − 1/q is nonnegligible. e running time of C is the upper bounded running time of the algorithm H 3 hash query (t 1 ) executed q 1 times, which is (O(q 1 · t 1 )). Now the algorithm used in the simulation S is polynomial-time computable, O(C) � O(q 1 ). It can be noted that q 1 is in polynomial(k). erefore, O(C) ≈ O(polynomial(k)). Hence, simulator S is polynomial-time algorithm. Proof. We prove the above given theorem through proof by contradiction.
We know that ∀t ∈ T, R(t) � R 1 (t), R 2 (t), . . . , R d (t)}. We assume that there is at least one proof, say, the x th instance (for some x ∈ T) where the proof P(x) is not valid as per the Proof-Ver algorithm of the CRPPA protocol, but the aggregate verification for all the t ∈ T instances still passes the verification test as per the Verify-Proof algorithm.
As per the assumption above, the x th instance does not pass the verification test of Proof-Verify algorithm. Hence, But ∀t ∈ T instances of the data possession proofs pass the verification test as per theVerify-Proof algorithm, which implies the following: e above also implies that ∀t ∈ T&t ≠ x instances of the data possession proofs also pass the verification test as per theVerify-Proof algorithm, and hence, we get Dividing (48) by (49), we get Equation (50) shows that the x th instance passes the verification test of Verify-Proof algorithm which contradicts with equation (47) derived from the assumption. Hence, the theorem is proved.
In the following two subsections, we explain in brief how the mechanisms adopted in the proposed CRPPA scheme can prevent and detect type-V and type-VI attacks, respectively. □ 8.2.1. Security against Type-V Attack. Type-V attack can be launched in two different ways as discussed in Section 7.1.2. Hence, we need to detect an incorrect data auditing report generated by the auditor and also restrict the auditor from disclosing the random values of the challenge vectors in advance. Using the Verify-Proof algorithm of the proposed CRPPA scheme, any user, acting as audit-verifier, can verify correctness of the audit reports. We have established the completeness and the soundness of this algorithm in Lemma 5 and eorem 6, respectively. Second, the CRPPA protocol ensures that all parties, including the data auditor, CSP, and audit-verifier, generate the challenge vector chal from the hash-block of a public blockchain corresponding to the audit time, which is specified in the SLA. e hash-block values in the blockchain continuously get updated, and it is not feasible to guess what would be the value of the block for a future instance of time. Hence, the auditor cannot disclose to the CSP in advance the challenge vectors for a future time instance.

Security against Type-VI Attack.
Type-VI attack by the compromised selfish auditor can only be detected if (i) there is a timestamp associated for each audit report generated by the auditor, (ii) the auditor is not able to modify once the report is timestamped, and (iii) the timestamped report is publicly available for verification. In our proposed CRPPA scheme, the hash digests of the audit reports need to be inserted as a transaction into the public blockchain. A transaction in the blockchain is immutable, timestamped, and verified by the blockchain. Hence, a user, acting as auditverifier, can always verify the timeliness of the auditing task performed by the auditor, as explained in the Verify-Proof algorithm of the CRPPA protocol.

Performance Analysis and Comparisons
In this section, we evaluate the performance of the proposed CRPPA scheme on two factors. First, we compare our CRPPA scheme with the recent CLS-based group shared data auditing schemes which find their applications in FOG-CPS environments. We specifically point to the concerns of their application to FOG-CPS environments based on the necessary cryptographic requirements and security against six types of attacks possible in a FOG-CPS. Second, we provide the computational cost comparisons with the wellknown schemes in the remote data integrity checking field to understand the performance of the CRPPA scheme in the broad area of RDIC. Table 3 shows the comparison of the proposed CRPPA scheme with the schemes of Jaya et al. [23], Yang et al. [24], Hongbin et al. [39], Cui et al. [21], Armknecht et al. [48], Zhang et al. [25], Yu et al. [12], and Li et al. [62] w.r.t the necessary security property requirements of a FOG-CPS which include group shared data, the cryptographic techniques employed for generating security credentials of the FOG-CPS users, the tag-unforgeability of the metadata generation mechanism to protect from forged signature (type I and type II) and integrity proof forgery (type III), the data privacy of sensitive data of the edge user against the semi-trusted data auditor (type IV), reliability on the correctness (type V), and timeliness of the auditing tasks by the semi-trusted data auditor (type VI).

A Qualitative Comparison of the Proposed CRPPA Scheme.
We discuss the specific security limitations of the schemes in [12, 21, 23-25, 39, 48, 62] against our proposed CRPPA scheme. e schemes in [12, 21, 23-25, 39, 62] are susceptible to tag forgery and integrity proof forgery attacks (type I, type II, and type III). e auditor in the schemes in [12, 21, 23-25, 39, 48, 62] after executing a large number of challenge-response instants can extract data file blocks or tags, i.e., these schemes are susceptible to type-IV attack and do not provide zero-knowledge data privacy against the auditor. Schemes in [12, 21, 23-25, 39, 48, 62] are susceptible to type-V attack and do not provide any mechanism to prevent the collusion of auditor and CSP on the random challenge vectors in advance used as a part of data auditing. Type-VI attack is possible in the schemes in [12, 21, 23-25, 39, 48, 62] where the auditor can delay or skip auditing tasks without even getting detected. us, these schemes in [12, 21, 23-25, 39, 48, 62] lack correctness and timeliness reliability of data auditing tasks by the auditor. Our proposed CRPPA is secure against all the six types of attacks and hence provides better security for FOG-CPS than the schemes in [12, 21, 23-25, 39, 48, 62].
Further, Table 4 presents various difficulty assumptions employed in the proposed CRPPA scheme and the schemes in [12, 21, 23-25, 39, 48, 62] to provide security against the six types of attack scenarios. e security against type-I and type-II attacks in [21, 23-25, 39, 48, 62] and our proposed CRPPA scheme is based on CDH assumption. e security against type-III attack in the schemes [23,39] is based on the DL assumption, that in scheme [25] is based on CDH assumption, and that in scheme [48] and our CRPPA scheme is based on the CDH and DL assumptions. e security against type-IV attack in scheme [23] is based on CDH assumption and that in schemes [12,39] is based on the oneway property of a hash function. In our proposed CRPPA scheme and in scheme [24], the security against type-IV attack is based on DL assumption. e security against type-V attack in scheme [48] and our CRPPA scheme is based on the consensus mechanism of blockchain and that in scheme [25] is based on proof-of-work mechanism in blockchain. Finally, our proposed CRPPA scheme and the scheme in [25] provide security against type-VI based on the immutability property of blockchain.

Computation Cost.
To understand the performance of the proposed CRPPA scheme in the broad area of RDIC, we consider three well-known RDIC schemes. e first is Li et al.'s CLS-based group shared data auditing scheme [62], and we refer to this scheme as certificateless-RDIC scheme. e second scheme is a ID-based data privacy-preserving scheme proposed by Yu et al. [12], and we refer to this scheme as ID-RDIC scheme. e third is Zhang et al.'s scheme [25] that employs blockchain technology for verifying data auditing tasks by the auditor, and we refer to this scheme as blockchain-RDIC.
A detailed comparison of cryptographic operations cost is performed on the proposed CRPPA scheme w.r.t to schemes in [12,25,62]. Tables 5-7 show the cryptographic operation cost at the auditor, the CSP, and the user, respectively. We consider only the operations that have a significant impact on the performance of the schemes, and these operations are hash-to-element in G 1 , exponentiation in G 1 , multiplication in G 1 and G 2 , and bilinear pairing operation. Let us denote their costs as T H , T exp G 1 , T mul G 1 , T mul G 2 , and T p , respectively. e value c in the tables corresponds to the number of challenged blocks in one challenge instance, the value b corresponds to the number of blocks for which tags are generated, and the value t corresponds to the number of challenge instances.
We have derived the cryptographic operations cost for each of the schemes in [12,25,62] by studying and analyzing each algorithm corresponding to the tag generation by the user, the proof generation by the CSP, and the proof verification by the auditor, and accordingly the significant cryptographic operation costs for each of the schemes are provided in Tables 5-7. e cryptographic operation costs in Tables 5-7 are for a single user, and the cryptographic operation costs for group of users can be calculated accordingly.

Experimentation
Results. In Section 9.1, through a qualitative comparison of our proposed CRPPA scheme w.r.t the existing schemes in [12, 21, 23-25, 39, 48, 62], we have shown that the proposed protocol achieves a unique combination of security objectives, which has not been achieved by any of the existing protocols. Table 3 clearly summarizes the additional security objectives that we gain with respect to the existing approaches. In Section 8, through rigorous mathematical analysis, we have established the claimed security properties of the proposed protocol. In this Table 3: Comparison of the proposed CRPPA scheme with the schemes in [12, 21, 23-25, 39, 48, 62] against six types of attacks.
Proposed CRPPA scheme subsection, through experimental evaluations, our objective is to demonstrate that we achieve these additional security objectives with almost no or marginal additional cost. We evaluate the performance of the proposed CRPPA scheme based on the computation cost of tag generation by the user, proof generation by the CSP, and proof verification by the data auditor against the schemes in [12,25,62]. e cost for the tag-generation mechanism for the user can be split into two types. e first is an offline tag-generation mechanism where some of the operations in the tag-generation mechanism can be calculated offline, independent of the file's data blocks.
e second is the online tag-generation cost dependent on the file's data blocks.
We have performed the experimental computation cost analysis with the help of the PBC library [76] on an intel i5-6200 CPU@2.30 GHz and 4 GB DDR4 RAM for simulating the CSP and with the help of Android PBC [77] on a Quadcore Cortex-A7 mobile processor@1.6 GHz and 2 GB RAM for simulating the edge user device and edge data auditor device. e benchmark execution time in milliseconds for each cryptographic operation T H , T exp G 1 , T mul G 1 , T mul G 2 , and T p is calculated on both the Linux OS PC device and Android OS mobile device and is shown in Table 8. Using the benchmark execution times in Table 6 and the number of  cryptographic operations from Tables 5-7, we derive the computation cost in seconds for online and offline tag generation by the user for different file sizes, proof generation by the CSP, and proof verification by the data auditor based on the number of challenged blocks. Figure 1 shows the results obtained from the above experimentation. From this figure, we can observe that the computation cost, in seconds, of tag generation (offline and online) is higher than that of proof generation and verification. is is obvious since the tag generation is executed for a complete data file and by a resource-constrained edge user device, whereas the proof generation and verification are executed for only the challenged number of blocks. It can also be observed that the online tag-generation cost is approximately 75% lower compared to offline cost. For instance, for a filesize of 1000 blocks, the offline cost is 10 seconds, whereas the online cost is only 2.5 seconds. e reason is that the users can precompute some operations beforehand to reduce the computational load required for online tag generation. It can be noted that although the taggeneration cost by an edge user device is higher, it is only a one-time process for a file, unlike the proof generations and verifications which are executed periodically. e proof generation cost by the cloud is comparatively very low compared to proof-verification cost by the data auditor since the cloud has higher computational power. In contrast, the data auditor is an edge device with low computational resources. is is the reason for which we have outlined few mechanisms in Section 5 to choose the data auditor from the group of edge devices to distribute the computational load among the edge devices.
Overall, from Figure 1, we can conclude that the computation costs of our proposed CRPPA scheme are comparable to the costs of the existing schemes in [12,25,62].

Conclusions and Future Work
In this paper, first, we have performed a detailed cryptanalysis of two CLPKC-based privacy-preserving shared data auditing schemes to pinpoint the exact vulnerabilities in their metadata generation mechanisms. Second, we have proposed a novel group shared data auditing protocol tailored to the specific security requirements of a FOG-CPS. e proposed data auditing protocol takes advantage of the localized storage and computing facilities available at the edge of the FOG-CPS network by delegating an edge device geographically close to the storage resources to perform the data auditing task. Our proposed protocol ensures zeroknowledge data privacy against the data auditor and can provide the reliability of the data auditing tasks done by a data auditor. We ensured the reliability of auditing tasks in two ways: enabling any user to verify the data auditing reports generated by the auditor and detect any procrastination of auditing tasks done by the auditor and ensuring that the challenge vectors are generated from a time-varying and verifiable universal source of randomness to restrict auditor and CSP collusion on the challenge vectors in advance. We have proved that the metadata generated by our protocol are unforgeable and are secure against both type-I and type-II attacks in the random oracle model setting. We have also established proof in support of the claimed zeroknowledge privacy and the reliability properties of our proposed protocol. e comparative performance evaluations establish the efficiency of our proposed protocol. As future work, we plan to incorporate user revocation, support data dynamics, and establish a collective auditing mechanism among the edge devices in a distributed way.

Data Availability
e data used to support the findings of this study are included within the article.

Conflicts of Interest
e authors declare that there are no conflicts of interest regarding the publication of this paper.