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

Authors: Manohar Sai Burra; Soumyadev Maity
Journal: Security and Communication Networks
 (2022)

---

## Abstract

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 FOG-CPS 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 CLPKC-based privacy-preserving group shared data auditing schemes. The 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.


---

## Body

## 1. 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–8] is emerging as a new research domain to address the data management issues of CPS. The 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 theavailability 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 [10–40] 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. The 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–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–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. This problem of IBC is known as the key escrow problem, in literature [45]. The 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–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. This 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. The second concern is regarding the reliability of the auditing service provided by a semi-trusted data auditor. The 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. The 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. The 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.The CLPKC-based group shared data auditing protocols proposed in [16–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 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 above-mentioned 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. The 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. The 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. The comparative performance evaluations establish the efficiency of our proposed protocol.The rest of the paper is organized as follows. We review the literature in Section2, 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.Table1 shows the list of acronyms and their abbreviations used throughout the entire paper.Table 1
List of acronyms.
AcronymAbbreviationCPSCyber-physical systemRDICRemote data integrity checkingCSPCloud service providerPKIPublic key infrastructurePKCPublic key cryptographyCACertification authorityCRLCertificate revocation listIBCIdentity-based cryptographyPKGPrivate key generatorCLPKCCertificateless public key cryptographySLAService-level agreementPDPProvable data possessionKGCKey generation centerTPAThird-party auditorCLSCertificateless signatureCDHComputational Diffie–HellmanDDHDecisional Diffie–HellmanDLDiscrete logPPTProbabilistic polynomial timeDPTDeterministic polynomial timeROMRandom oracle modelCLS-RDICCertificateless signature-based remote data integrity checkingCRPPACertificateless reliable privacy-preserving auditingAdv1Adversary 1Adv2Adversary 2Adv3Adversary 3Adv4Adversary 4Adv5Adversary 5Adv6Adversary 6PBCPairing-based cryptography


## 2. 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.


### 2.1. FOG-CPSs

There 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. Therefore, 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. The 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. The scheme in [4] employs a lightweight signature mechanism to generate group signatures, which helps to handle batch authentication of edge nodes efficiently. The authors in [5] provided a framework for the user and data privacy in the FOG-enabled smart city network. The 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. The 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. The 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. The 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. Therefore, the works in [55–58] developed scalable public blockchain techniques for FOG-CPSs. The 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. The authors in [58] constructed a Ethereum blockchain for the resource-constrained device to provide security of the data generated from the CPS devices. They even designed a secure networked clock for blockchain data synchronization for the non-real-time CPS devices.


### 2.2. 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. The 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. The 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. The CSP computes a PDP proof corresponding to the challenge set and sends the PDP proof as a response to the cloud user. The 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-cryptography-based RDIC scheme called the proof of retrievability (POR) that utilizes efficient error-coding techniques. The main drawback of the scheme is that it supports only private verification. The 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.The majority of public key cryptography-based RDIC protocols [11, 12, 26–30, 33, 34, 37, 40] developed until now employ PKI or IBC [43]. The 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. The 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. The 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. The compromise of the master secret key of the PKG will result in a compromise of the security credentials of all the users. Thus, 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. Many RDIC schemes [16, 18, 19, 22, 23, 35, 36, 39, 62–66] have been proposed based on CLPKC. He et al.’s [64] certificateless public auditing scheme for cloud-assisted WBANs is not a privacy-preserving scheme. Kang et al. [65] improved He et al.’s [64] scheme to provide privacy-preserving property, but it lacks public verifiability. Sasikala et al. [35] proposed a certificateless RDIC scheme for the cloud using lattices, but it was proved to be insecure in [36].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. The 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 privacy-preserving 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. The 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. Thus, 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. Therefore, 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.


## 2.1. FOG-CPSs

There 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. Therefore, 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. The 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. The scheme in [4] employs a lightweight signature mechanism to generate group signatures, which helps to handle batch authentication of edge nodes efficiently. The authors in [5] provided a framework for the user and data privacy in the FOG-enabled smart city network. The 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. The 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. The 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. The 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. Therefore, the works in [55–58] developed scalable public blockchain techniques for FOG-CPSs. The 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. The authors in [58] constructed a Ethereum blockchain for the resource-constrained device to provide security of the data generated from the CPS devices. They even designed a secure networked clock for blockchain data synchronization for the non-real-time CPS devices.


## 2.2. 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. The 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. The 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. The CSP computes a PDP proof corresponding to the challenge set and sends the PDP proof as a response to the cloud user. The 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-cryptography-based RDIC scheme called the proof of retrievability (POR) that utilizes efficient error-coding techniques. The main drawback of the scheme is that it supports only private verification. The 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.The majority of public key cryptography-based RDIC protocols [11, 12, 26–30, 33, 34, 37, 40] developed until now employ PKI or IBC [43]. The 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. The 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. The 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. The compromise of the master secret key of the PKG will result in a compromise of the security credentials of all the users. Thus, 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. Many RDIC schemes [16, 18, 19, 22, 23, 35, 36, 39, 62–66] have been proposed based on CLPKC. He et al.’s [64] certificateless public auditing scheme for cloud-assisted WBANs is not a privacy-preserving scheme. Kang et al. [65] improved He et al.’s [64] scheme to provide privacy-preserving property, but it lacks public verifiability. Sasikala et al. [35] proposed a certificateless RDIC scheme for the cloud using lattices, but it was proved to be insecure in [36].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. The 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 privacy-preserving 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. The 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. Thus, 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. Therefore, 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.


## 3. 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.


### 3.1. Negligible Function (ξ)

A functionξx:ℕ⟶ℝ is called negligible, if ∀c∈ℕ, ∃Qc∈ℕ such that ∀x>Qc, ξx<1/xc.In cryptography, a scheme is said to be “provably secure,” if the probability of security failure is a negligible function of the inputx which is the security parameter (cryptographic key length) of the security scheme.


### 3.2. General Forking Lemma [67]

Letx 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 h1,…,hv as inputs where each hi value ∀i=1,…,v is randomly drawn from the set H for some v≥1. The algorithm outputs a pair I,θ where I∈0,…,v and θ is called side output.Acceptance. We say that the algorithm A has accepted the inputs if it uses one of the values in h1,…,hv to generate its side output θ. If it accepts, then I is the index of the inputs 1,2,…,v. If it does not use any of the values in h1,…,hv to generate θ, then I=0.Acceptance Probability. The acceptance probability for the above-mentioned randomized algorithm A is defined as Pracc=PrI≠.Forking. The forking protocol on algorithm A, denoted as ForkAx, is as shown below:(1)
$← Random Tape;(2)
h1,…,hv←RH;(3)
I,θ←Ax,h1,…,hv;$;(4)
IfI=0 then return 0;(5)
hI′,…,hv′←RH;(6)
I′,θ′←Ax,h1,…,hI−1,hI′,…,hv′;$;(7)
If (I≠I′ or hI=hI′) then return 0;(8)
else return 1;The above protocolForkAx actually consists of two rounds. In the first round, we input the value of x, a randomly chosen set of h1,…,hv values, and a random tape $. The 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 h1,…,hv is updated keeping h1 to hI−1 the same. The 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 hI and hI′ are same. Otherwise, the protocol ForkAx 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 hI and hI′.Forking Probability. The forking probability for the above protocol ForkAx is defined as Prfrk=PrForkAx=1 where x is a randomly generated global parameter x. Bellare et al. [67] proved that Prfrk≥Pracc⋅Pracc/q−1/H.


### 3.3. Bilinear Map

Consider two cyclic multiplicative groupsG1, G2, for G1 = G2 = q, where q is a large prime integer. A bilinear map [61] is a function of the form e^:G1×G1⟶G2, that satisfies the following properties.Bilinearity.∀m,n∈Fq∗,∀X,Y∈G1, eXm,Yn=eX,Ymn.Non-Degeneracy. eX,Y≠1 for all values of X and Y, where 1 is the identity element of G2.Computability. There exists a polynomial-time algorithm to compute e^.The bilinear map can be implemented using a Weil pairing [43] or a Tate pairing [68].


### 3.4. Computational Diffie–Hellman (CDH) Problem

LetG1 be a cyclic multiplicative group of order q, and let g be the generator of the group. The CDH problem [69] in G1 is as follows: given q,G1,g,h1,h2 for some h1,h2∈G1, where h1=gα and α∈Zq∗, compute h2α.The decision version of the above problem, also known as the decisional Diffie–Hellman (DDH) problem, is defined as follows: givenq,G1,g,h1,h2,h3 for some h1,h2, and h3∈G1, where h1=gα,h2=gβ, and h3=gγ, for α,β,γ∈Zq∗, decide whether gαβ=gγ. The DDH problem is easy to decide in G1 if there exists a bilinear map in group G1. However, till date, there exists no efficient algorithm to compute h2α in polynomial time, and thus CDH is believed to be a hard problem in group G1.


### 3.5. 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 parameterk as input and outputs public parameter-list params and a secret master key α for the key generation center (KGC). The 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. The user sends its identityIDu to KGC as part of the request. The input to this deterministic polynomial-time (DPT) algorithm is the identity IDu, public parameters params, and master secret key α, and it outputs the partial-private-key Du. The KGC transfers the partial-private-key Du to the corresponding user through a secure side channel.(iii)
Set-Secret-Value: this algorithm is executed by a useru. The input to this PPT algorithm is params and IDu and it outputs a secret value βu which is kept secret to the user u only.(iv)
Private-Key-Gen: a useru runs this PPT algorithm to generate its private key as Du,βu.(v)
Set-Public-Key: useru runs this DPT algorithm with its identity IDu, full private key Du,βu, and the public parameters params as the inputs to generate its public key Pu. User u announces its public key publicly without the need for any certificate.(vi)
Sign: this PPT algorithm is executed by a useru to generate a signature on a given message m∈0,1∗. The algorithm takes m, IDu, the full private key Du,βu, and the public parameters params as the inputs and produces Sigm as the signature.(vii)
Verify: the input to this DPT algorithm ism, Sigm, params, IDu, and Pu and outputs accept if the signature is valid, or reject otherwise. The 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 Section3.7 which describes these two attack scenarios in detail.


### 3.6. 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 Section3.5, contributes the first four algorithms, namely, setup, partial-private-key-extract, private-key-gen, and set-public-key. The rest of the algorithms of CLS-RDIC are briefed below:(i)
Tag-Gen: a cloud user runs this algorithm with a data blockm, corresponding authenticating information w = (file-id block−index public info. of user), params , and IDu as inputs to generate a tag σ, where m∈ℳ, for ℳ is the message space. For every data block uploaded in the data file IDF, 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 withc (number of data blocks challenged), IDF (id of the data file), params, and inputs from a pseudorandom source to generate a challenge vector called chal. The 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 requestchal from the TPA. The inputs to this algorithm are chal,params,σi,andmi (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 inputsP,chal,IDF,and params and outputs accept if the proof P is valid, or reject otherwise.The security requirements for a CLS-RDIC scheme are discussed in detail in the following subsection.


### 3.7. 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. The games corresponding to the above three types of adversaries are defined in the following three subsections.


#### 3.7.1. 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. The 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 partial-private-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. The 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 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 challengerC and an adversary Adv1, models the hypothetical type-I attacker discussed above. The game consists of the following phases.Setup. The 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 challengerC. C is required to send back the correct output.(ii)
Partial-Private-Key Query: Adv1 can submit any identityIDu 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 identityIDu 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 identityIDu 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 identityIDu and a public key Pu′ of its choice to C. Challenger C updates the public key corresponding to IDu as Pu′.(vi)
Tag-Gen Query: Adv1 can submit any tuplem,w,IDu 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.Forge-Tag. Finally, Adv1 outputs a tuple σ′,m′,w′,IDu′, where σ′ is a forged tag on the forged data block m′ with authenticating information w′ for user IDu′.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 IDu′, (ii) Adv1 has not queried for the secret value corresponding to the identity IDu′, (iii) Adv1 does not query for the partial-private-key and replace public key simultaneously for the identity IDu′, and (iv) Adv1 has not queried the tag for the m′,w′,IDu′ tuple at any stage.


#### 3.7.2. 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 keymsk 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 challengerC and an adversary Adv2, models the hypothetical type-II attacker discussed above. The 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.(i)
Hash Query: this query is the same as the hash query in game-1.(ii)
Secret-Value Query: same as the Secret-Value query defined in game-1.(iii)
Public-Key Query: same as the Public-Key query defined in game-1.(iv)
Tag-Gen Query: same as the Tag-Gen query defined in game-1.It can be noted here that we do not include the Partial-Private-Key Query for Adv2 since it can calculate the partial-private-key of any user usingmsk it has in its possession.Forge-Tag. Finally, Adv2 outputs a tuple σ′,m′,w′,IDu′, where σ′ is the forged tag on the forged data block m′ with authentication information w′ for user IDu′.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 IDu′, (ii) Adv2 has not queried for the secret value corresponding to the IDu′, and (iii) Adv2 has not queried for the tag for the m′,w′,IDu′ 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. Thus, 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.


#### 3.7.3. 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 challengerC and an adversary Adv3, models the hypothetical type-III attacker discussed above. The game consists of the following phases.Setup. The 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 IDF. The 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 indexi of the data file IDF. 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 indexi of the data file IDF 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 IDF 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.


## 3.1. Negligible Function (ξ)

A functionξx:ℕ⟶ℝ is called negligible, if ∀c∈ℕ, ∃Qc∈ℕ such that ∀x>Qc, ξx<1/xc.In cryptography, a scheme is said to be “provably secure,” if the probability of security failure is a negligible function of the inputx which is the security parameter (cryptographic key length) of the security scheme.


## 3.2. General Forking Lemma [67]

Letx 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 h1,…,hv as inputs where each hi value ∀i=1,…,v is randomly drawn from the set H for some v≥1. The algorithm outputs a pair I,θ where I∈0,…,v and θ is called side output.Acceptance. We say that the algorithm A has accepted the inputs if it uses one of the values in h1,…,hv to generate its side output θ. If it accepts, then I is the index of the inputs 1,2,…,v. If it does not use any of the values in h1,…,hv to generate θ, then I=0.Acceptance Probability. The acceptance probability for the above-mentioned randomized algorithm A is defined as Pracc=PrI≠.Forking. The forking protocol on algorithm A, denoted as ForkAx, is as shown below:(1)
$← Random Tape;(2)
h1,…,hv←RH;(3)
I,θ←Ax,h1,…,hv;$;(4)
IfI=0 then return 0;(5)
hI′,…,hv′←RH;(6)
I′,θ′←Ax,h1,…,hI−1,hI′,…,hv′;$;(7)
If (I≠I′ or hI=hI′) then return 0;(8)
else return 1;The above protocolForkAx actually consists of two rounds. In the first round, we input the value of x, a randomly chosen set of h1,…,hv values, and a random tape $. The 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 h1,…,hv is updated keeping h1 to hI−1 the same. The 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 hI and hI′ are same. Otherwise, the protocol ForkAx 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 hI and hI′.Forking Probability. The forking probability for the above protocol ForkAx is defined as Prfrk=PrForkAx=1 where x is a randomly generated global parameter x. Bellare et al. [67] proved that Prfrk≥Pracc⋅Pracc/q−1/H.


## 3.3. Bilinear Map

Consider two cyclic multiplicative groupsG1, G2, for G1 = G2 = q, where q is a large prime integer. A bilinear map [61] is a function of the form e^:G1×G1⟶G2, that satisfies the following properties.Bilinearity.∀m,n∈Fq∗,∀X,Y∈G1, eXm,Yn=eX,Ymn.Non-Degeneracy. eX,Y≠1 for all values of X and Y, where 1 is the identity element of G2.Computability. There exists a polynomial-time algorithm to compute e^.The bilinear map can be implemented using a Weil pairing [43] or a Tate pairing [68].


## 3.4. Computational Diffie–Hellman (CDH) Problem

LetG1 be a cyclic multiplicative group of order q, and let g be the generator of the group. The CDH problem [69] in G1 is as follows: given q,G1,g,h1,h2 for some h1,h2∈G1, where h1=gα and α∈Zq∗, compute h2α.The decision version of the above problem, also known as the decisional Diffie–Hellman (DDH) problem, is defined as follows: givenq,G1,g,h1,h2,h3 for some h1,h2, and h3∈G1, where h1=gα,h2=gβ, and h3=gγ, for α,β,γ∈Zq∗, decide whether gαβ=gγ. The DDH problem is easy to decide in G1 if there exists a bilinear map in group G1. However, till date, there exists no efficient algorithm to compute h2α in polynomial time, and thus CDH is believed to be a hard problem in group G1.


## 3.5. 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 parameterk as input and outputs public parameter-list params and a secret master key α for the key generation center (KGC). The 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. The user sends its identityIDu to KGC as part of the request. The input to this deterministic polynomial-time (DPT) algorithm is the identity IDu, public parameters params, and master secret key α, and it outputs the partial-private-key Du. The KGC transfers the partial-private-key Du to the corresponding user through a secure side channel.(iii)
Set-Secret-Value: this algorithm is executed by a useru. The input to this PPT algorithm is params and IDu and it outputs a secret value βu which is kept secret to the user u only.(iv)
Private-Key-Gen: a useru runs this PPT algorithm to generate its private key as Du,βu.(v)
Set-Public-Key: useru runs this DPT algorithm with its identity IDu, full private key Du,βu, and the public parameters params as the inputs to generate its public key Pu. User u announces its public key publicly without the need for any certificate.(vi)
Sign: this PPT algorithm is executed by a useru to generate a signature on a given message m∈0,1∗. The algorithm takes m, IDu, the full private key Du,βu, and the public parameters params as the inputs and produces Sigm as the signature.(vii)
Verify: the input to this DPT algorithm ism, Sigm, params, IDu, and Pu and outputs accept if the signature is valid, or reject otherwise. The 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 Section3.7 which describes these two attack scenarios in detail.


## 3.6. 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 Section3.5, contributes the first four algorithms, namely, setup, partial-private-key-extract, private-key-gen, and set-public-key. The rest of the algorithms of CLS-RDIC are briefed below:(i)
Tag-Gen: a cloud user runs this algorithm with a data blockm, corresponding authenticating information w = (file-id block−index public info. of user), params , and IDu as inputs to generate a tag σ, where m∈ℳ, for ℳ is the message space. For every data block uploaded in the data file IDF, 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 withc (number of data blocks challenged), IDF (id of the data file), params, and inputs from a pseudorandom source to generate a challenge vector called chal. The 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 requestchal from the TPA. The inputs to this algorithm are chal,params,σi,andmi (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 inputsP,chal,IDF,and params and outputs accept if the proof P is valid, or reject otherwise.The security requirements for a CLS-RDIC scheme are discussed in detail in the following subsection.


## 3.7. 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. The games corresponding to the above three types of adversaries are defined in the following three subsections.


### 3.7.1. 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. The 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 partial-private-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. The 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 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 challengerC and an adversary Adv1, models the hypothetical type-I attacker discussed above. The game consists of the following phases.Setup. The 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 challengerC. C is required to send back the correct output.(ii)
Partial-Private-Key Query: Adv1 can submit any identityIDu 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 identityIDu 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 identityIDu 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 identityIDu and a public key Pu′ of its choice to C. Challenger C updates the public key corresponding to IDu as Pu′.(vi)
Tag-Gen Query: Adv1 can submit any tuplem,w,IDu 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.Forge-Tag. Finally, Adv1 outputs a tuple σ′,m′,w′,IDu′, where σ′ is a forged tag on the forged data block m′ with authenticating information w′ for user IDu′.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 IDu′, (ii) Adv1 has not queried for the secret value corresponding to the identity IDu′, (iii) Adv1 does not query for the partial-private-key and replace public key simultaneously for the identity IDu′, and (iv) Adv1 has not queried the tag for the m′,w′,IDu′ tuple at any stage.


### 3.7.2. 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 keymsk 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 challengerC and an adversary Adv2, models the hypothetical type-II attacker discussed above. The 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.(i)
Hash Query: this query is the same as the hash query in game-1.(ii)
Secret-Value Query: same as the Secret-Value query defined in game-1.(iii)
Public-Key Query: same as the Public-Key query defined in game-1.(iv)
Tag-Gen Query: same as the Tag-Gen query defined in game-1.It can be noted here that we do not include the Partial-Private-Key Query for Adv2 since it can calculate the partial-private-key of any user usingmsk it has in its possession.Forge-Tag. Finally, Adv2 outputs a tuple σ′,m′,w′,IDu′, where σ′ is the forged tag on the forged data block m′ with authentication information w′ for user IDu′.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 IDu′, (ii) Adv2 has not queried for the secret value corresponding to the IDu′, and (iii) Adv2 has not queried for the tag for the m′,w′,IDu′ 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. Thus, 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.


### 3.7.3. 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 challengerC and an adversary Adv3, models the hypothetical type-III attacker discussed above. The game consists of the following phases.Setup. The 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 IDF. The 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 indexi of the data file IDF. 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 indexi of the data file IDF 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 IDF 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.


## 3.7.1. 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. The 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 partial-private-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. The 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 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 challengerC and an adversary Adv1, models the hypothetical type-I attacker discussed above. The game consists of the following phases.Setup. The 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 challengerC. C is required to send back the correct output.(ii)
Partial-Private-Key Query: Adv1 can submit any identityIDu 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 identityIDu 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 identityIDu 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 identityIDu and a public key Pu′ of its choice to C. Challenger C updates the public key corresponding to IDu as Pu′.(vi)
Tag-Gen Query: Adv1 can submit any tuplem,w,IDu 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.Forge-Tag. Finally, Adv1 outputs a tuple σ′,m′,w′,IDu′, where σ′ is a forged tag on the forged data block m′ with authenticating information w′ for user IDu′.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 IDu′, (ii) Adv1 has not queried for the secret value corresponding to the identity IDu′, (iii) Adv1 does not query for the partial-private-key and replace public key simultaneously for the identity IDu′, and (iv) Adv1 has not queried the tag for the m′,w′,IDu′ tuple at any stage.


## 3.7.2. 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 keymsk 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 challengerC and an adversary Adv2, models the hypothetical type-II attacker discussed above. The 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.(i)
Hash Query: this query is the same as the hash query in game-1.(ii)
Secret-Value Query: same as the Secret-Value query defined in game-1.(iii)
Public-Key Query: same as the Public-Key query defined in game-1.(iv)
Tag-Gen Query: same as the Tag-Gen query defined in game-1.It can be noted here that we do not include the Partial-Private-Key Query for Adv2 since it can calculate the partial-private-key of any user usingmsk it has in its possession.Forge-Tag. Finally, Adv2 outputs a tuple σ′,m′,w′,IDu′, where σ′ is the forged tag on the forged data block m′ with authentication information w′ for user IDu′.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 IDu′, (ii) Adv2 has not queried for the secret value corresponding to the IDu′, and (iii) Adv2 has not queried for the tag for the m′,w′,IDu′ 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. Thus, 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.


## 3.7.3. 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 challengerC and an adversary Adv3, models the hypothetical type-III attacker discussed above. The game consists of the following phases.Setup. The 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 IDF. The 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 indexi of the data file IDF. 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 indexi of the data file IDF 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 IDF 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.


## 4. 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.


### 4.1. Brief Description of Jaya et al.’s Scheme [23]

The algorithms involved in the tag generation of the protocol proposed by Jaya et al. [23] are described as follows. The 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. The KGC runs the setup algorithm and performs the following steps:(1)
Selectsq,g,G1,G2,e as described in our Preliminaries section.(2)
Chooses a master secret keyα∈Zq∗ at random and sets the KGC’s public key Ppub=gα. The KGC also chooses another random value γo∈Zq∗ and sends it confidentially to the group manager (GM).(3)
Selects three secure hash functionsH1:0,1∗⟶G1, H2:0,1∗⟶G1, and h.:G1⟶Zq∗.The KGC publishes the public parametersparams=G1,G2,q,e^,g,Ppub,H1,H2,h..Join. Any user entity Uj, for 1≤j≤d, which is part of network and wants to join a group, requests the GM. The GM after reviewing the request generates a group key δUj for the user where δUj=gγo⋅H1IDUjγo and sends δUj 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 IDUj,δUj as part of the request. The KGC validates both IDUj,δUj as per the verification equation below:(1)eδUj,g=eg⋅H1IDUj,gγo.If invalid, KGC aborts, else generatesQUj=H1IDUj and DUj=QUjα where IDUj is the unique public identity and DUj is the partial private key of the user Uj. KGC forwards DUj to the corresponding user Uj via a secure channel.SetSecretValue. User Uj chooses the values βUj∈Zq∗ and g1∈G1 at random and stores with itself βUj as a secret. The user computes ζ=g1βUj and makes it public.PvtKeyGen. User Uj sets its private key SUj = DUj,βUj.SetPublicKey. User Uj computes its public key as PKUj=gβUj.SignGen. User Uj generates tag for a block mi of the file M=m1,m2,…,mn with file identity Fid, where n is the number of blocks, mi∈Zq∗.(1)
The group userUj computes the tag σi as σi=DUj⋅g1miH2wiβUj, where wi=Fidni.(2)
The group userUj uploads its message block along with authenticating information and the generated tag mi,wi,σ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)eσi,g=eH1IDUjmi,Ppub⋅eg1mi,g⋅eH2wi,PKUj.


### 4.2. Analysis of Jaya et al.’s Scheme

#### 4.2.1. Type-I Attack Analysis

Suppose a type-I attacker targets userUj 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 PKUj of the victim user, and (3) a valid tuple mi,wi,σi for the i′th block of the data file of user Uj, 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 mi′, keeping the authenticating information same as wi and replacing the original public key PKUj of the victim user by a forged public key PKUj′.(1)
Generates a forged data blockmi′ of its choice.(2)
Calculatesk=mi′/mi, where mi is the data block to be replaced. Note that mi′=kmi.(3)
Generates a forged public keyPKUj′ for user Uj as PKUj′=PKUjk. It replaces the original public key PKUj of the victim user by the forged public key PKUj′.(4)
Computes the forged tag asσi′=σik.(5)
The attacker outputs the tuplemi′,wi,σi′.Note that the attacker does not need access to the partial-private keyDUj or the personal secret key βUj of the target user Uj.Lemma 1.
The forged tagσi′ generated using the above mechanism is a valid tag on the forged data block mi′ with authenticating information wi under the public values IDUj,PKUj′ of the victim user Uj.Proof.
In order to prove the lemma, it is sufficient to show that the tuplemi′,wi,σi′ satisfies the correctness equation as shown in equation (2) under the replaced public key PKUj′ of user IDUj. The correctness proof is given below:(3)eσi′,g=eσik,g=eDUj⋅g1mi⋅H2wikβUj,g=eDUjkmi⋅g1kmiH2wikβUj,g=eDUjkmi,g⋅eg1kmi,g⋅eH2wikβUj,g=eH1IDUjαkmi,g⋅eg1mi′,g.eH2wi,gkβUj=eH1IDUjkmi,gα⋅eg1mi′,g⋅eH2wi,PKUjk=eH1IDUjmi′,Ppub⋅eg1mi′,g⋅eH2wi,PKUj′.


#### 4.2.2. Type-II Attack Analysis

Like type-I attack, a type-II attacker also has the access to all public parameters, including the public keyPKUj of the victim user Uj, and a valid tuple mi,wi,σi for some i. In addition, it has the master secret key α in its possession. The attacker can execute the following steps to generate a forged tag σi′ for a forged data block mi′, keeping the authenticating information same as wi.(1)
Generates a forged data blockmi′ of its choice.(2)
CalculatesDUj=H1IDUjα.(3)
CalculatesX=DUj⋅g1mi(4)
CalculatesY=σi/X.(5)
Computes the forged tag asσi′=DUj⋅g1mi′.Y.(6)
The attacker outputs the tuplemi′,wi,σi′.Note that in the above attack, the attacker does not need access to the personal secret keyβUj of the victim user Uj. Also, it does not replace the original public key PKUj of the user.Lemma 2.
The forged tagσi′ generated using the above mechanism is a valid tag on the forged data block mi′ with authenticating information wi under the public values IDUj,PKUj of the victim user Uj.Proof.
Let us prove the lemma by showing the validity of the forged tuplemi′,wi,σi′ under the public key PKUj of user Uj, as per equation (2). The correctness proof is given below:(4)Y=σiX=DUj⋅g1miH2wiβUjDUj⋅g1mi=H2wiβUj,and hence(5)eσi′,g=eDUj⋅g1mi′⋅Y,g=eDUjmi′,g⋅eg1mi′,g⋅eY,g=eH1IDUjαmi′,g⋅eg1mi′,g⋅eH2wiβUj,g=eH1IDUjmi′,gα⋅eg1mi′,g⋅eH2wi,gβUj=eH1IDUjmi′,Ppub⋅eg1mi′,g⋅eH2wi,PKUj.


#### 4.2.3. Remarks on the Analysis

The above analysis shows that if an attacker (type I or type II) obtains a valid data block and tag pairmi,σi corresponding to some block i of a data file Fid belonging to a victim user Uj, then it can replace the block by generating a valid tag σi′ for a forged block mi′ while keeping the authenticating information same as wi=Fidni. More importantly, we can also observe that the forged block mi′ 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. This 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 wi of a block with the public key of the user. This 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 tag-generation mechanism which is provably secure against both type-I and type-II attacks.


### 4.3. Brief Overview on the Tag-Generation Mechanism of the Scheme in [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.Tag-Gen. Using this algorithm, a group user Uj for 1≤j≤d generates tag for a block mi of the file M=m1,m2,…,mn with file identity Fid where n is the number of blocks, mi∈Zq∗. User Uj computes the tag σi as(6)σi=DUjmiH2wiβUj,where wi=i‖Fid. The partial private key is calculated as DUj=H1IDUj+ηα where α,η∈Zq∗ are secretly kept with the group manager, which acts as the KGC in this protocol. User Uj sends the message block and tag pair mi,σi to the cloud and updates a public log file with the values index i, the user public identity H1IDUj+η, and the user public key PUj=gβUj where βUj is secret to the user Uj.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.


## 4.1. Brief Description of Jaya et al.’s Scheme [23]

The algorithms involved in the tag generation of the protocol proposed by Jaya et al. [23] are described as follows. The 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. The KGC runs the setup algorithm and performs the following steps:(1)
Selectsq,g,G1,G2,e as described in our Preliminaries section.(2)
Chooses a master secret keyα∈Zq∗ at random and sets the KGC’s public key Ppub=gα. The KGC also chooses another random value γo∈Zq∗ and sends it confidentially to the group manager (GM).(3)
Selects three secure hash functionsH1:0,1∗⟶G1, H2:0,1∗⟶G1, and h.:G1⟶Zq∗.The KGC publishes the public parametersparams=G1,G2,q,e^,g,Ppub,H1,H2,h..Join. Any user entity Uj, for 1≤j≤d, which is part of network and wants to join a group, requests the GM. The GM after reviewing the request generates a group key δUj for the user where δUj=gγo⋅H1IDUjγo and sends δUj 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 IDUj,δUj as part of the request. The KGC validates both IDUj,δUj as per the verification equation below:(1)eδUj,g=eg⋅H1IDUj,gγo.If invalid, KGC aborts, else generatesQUj=H1IDUj and DUj=QUjα where IDUj is the unique public identity and DUj is the partial private key of the user Uj. KGC forwards DUj to the corresponding user Uj via a secure channel.SetSecretValue. User Uj chooses the values βUj∈Zq∗ and g1∈G1 at random and stores with itself βUj as a secret. The user computes ζ=g1βUj and makes it public.PvtKeyGen. User Uj sets its private key SUj = DUj,βUj.SetPublicKey. User Uj computes its public key as PKUj=gβUj.SignGen. User Uj generates tag for a block mi of the file M=m1,m2,…,mn with file identity Fid, where n is the number of blocks, mi∈Zq∗.(1)
The group userUj computes the tag σi as σi=DUj⋅g1miH2wiβUj, where wi=Fidni.(2)
The group userUj uploads its message block along with authenticating information and the generated tag mi,wi,σ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)eσi,g=eH1IDUjmi,Ppub⋅eg1mi,g⋅eH2wi,PKUj.


## 4.2. Analysis of Jaya et al.’s Scheme

### 4.2.1. Type-I Attack Analysis

Suppose a type-I attacker targets userUj 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 PKUj of the victim user, and (3) a valid tuple mi,wi,σi for the i′th block of the data file of user Uj, 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 mi′, keeping the authenticating information same as wi and replacing the original public key PKUj of the victim user by a forged public key PKUj′.(1)
Generates a forged data blockmi′ of its choice.(2)
Calculatesk=mi′/mi, where mi is the data block to be replaced. Note that mi′=kmi.(3)
Generates a forged public keyPKUj′ for user Uj as PKUj′=PKUjk. It replaces the original public key PKUj of the victim user by the forged public key PKUj′.(4)
Computes the forged tag asσi′=σik.(5)
The attacker outputs the tuplemi′,wi,σi′.Note that the attacker does not need access to the partial-private keyDUj or the personal secret key βUj of the target user Uj.Lemma 1.
The forged tagσi′ generated using the above mechanism is a valid tag on the forged data block mi′ with authenticating information wi under the public values IDUj,PKUj′ of the victim user Uj.Proof.
In order to prove the lemma, it is sufficient to show that the tuplemi′,wi,σi′ satisfies the correctness equation as shown in equation (2) under the replaced public key PKUj′ of user IDUj. The correctness proof is given below:(3)eσi′,g=eσik,g=eDUj⋅g1mi⋅H2wikβUj,g=eDUjkmi⋅g1kmiH2wikβUj,g=eDUjkmi,g⋅eg1kmi,g⋅eH2wikβUj,g=eH1IDUjαkmi,g⋅eg1mi′,g.eH2wi,gkβUj=eH1IDUjkmi,gα⋅eg1mi′,g⋅eH2wi,PKUjk=eH1IDUjmi′,Ppub⋅eg1mi′,g⋅eH2wi,PKUj′.


### 4.2.2. Type-II Attack Analysis

Like type-I attack, a type-II attacker also has the access to all public parameters, including the public keyPKUj of the victim user Uj, and a valid tuple mi,wi,σi for some i. In addition, it has the master secret key α in its possession. The attacker can execute the following steps to generate a forged tag σi′ for a forged data block mi′, keeping the authenticating information same as wi.(1)
Generates a forged data blockmi′ of its choice.(2)
CalculatesDUj=H1IDUjα.(3)
CalculatesX=DUj⋅g1mi(4)
CalculatesY=σi/X.(5)
Computes the forged tag asσi′=DUj⋅g1mi′.Y.(6)
The attacker outputs the tuplemi′,wi,σi′.Note that in the above attack, the attacker does not need access to the personal secret keyβUj of the victim user Uj. Also, it does not replace the original public key PKUj of the user.Lemma 2.
The forged tagσi′ generated using the above mechanism is a valid tag on the forged data block mi′ with authenticating information wi under the public values IDUj,PKUj of the victim user Uj.Proof.
Let us prove the lemma by showing the validity of the forged tuplemi′,wi,σi′ under the public key PKUj of user Uj, as per equation (2). The correctness proof is given below:(4)Y=σiX=DUj⋅g1miH2wiβUjDUj⋅g1mi=H2wiβUj,and hence(5)eσi′,g=eDUj⋅g1mi′⋅Y,g=eDUjmi′,g⋅eg1mi′,g⋅eY,g=eH1IDUjαmi′,g⋅eg1mi′,g⋅eH2wiβUj,g=eH1IDUjmi′,gα⋅eg1mi′,g⋅eH2wi,gβUj=eH1IDUjmi′,Ppub⋅eg1mi′,g⋅eH2wi,PKUj.


### 4.2.3. Remarks on the Analysis

The above analysis shows that if an attacker (type I or type II) obtains a valid data block and tag pairmi,σi corresponding to some block i of a data file Fid belonging to a victim user Uj, then it can replace the block by generating a valid tag σi′ for a forged block mi′ while keeping the authenticating information same as wi=Fidni. More importantly, we can also observe that the forged block mi′ 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. This 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 wi of a block with the public key of the user. This 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 tag-generation mechanism which is provably secure against both type-I and type-II attacks.


## 4.2.1. Type-I Attack Analysis

Suppose a type-I attacker targets userUj 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 PKUj of the victim user, and (3) a valid tuple mi,wi,σi for the i′th block of the data file of user Uj, 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 mi′, keeping the authenticating information same as wi and replacing the original public key PKUj of the victim user by a forged public key PKUj′.(1)
Generates a forged data blockmi′ of its choice.(2)
Calculatesk=mi′/mi, where mi is the data block to be replaced. Note that mi′=kmi.(3)
Generates a forged public keyPKUj′ for user Uj as PKUj′=PKUjk. It replaces the original public key PKUj of the victim user by the forged public key PKUj′.(4)
Computes the forged tag asσi′=σik.(5)
The attacker outputs the tuplemi′,wi,σi′.Note that the attacker does not need access to the partial-private keyDUj or the personal secret key βUj of the target user Uj.Lemma 1.
The forged tagσi′ generated using the above mechanism is a valid tag on the forged data block mi′ with authenticating information wi under the public values IDUj,PKUj′ of the victim user Uj.Proof.
In order to prove the lemma, it is sufficient to show that the tuplemi′,wi,σi′ satisfies the correctness equation as shown in equation (2) under the replaced public key PKUj′ of user IDUj. The correctness proof is given below:(3)eσi′,g=eσik,g=eDUj⋅g1mi⋅H2wikβUj,g=eDUjkmi⋅g1kmiH2wikβUj,g=eDUjkmi,g⋅eg1kmi,g⋅eH2wikβUj,g=eH1IDUjαkmi,g⋅eg1mi′,g.eH2wi,gkβUj=eH1IDUjkmi,gα⋅eg1mi′,g⋅eH2wi,PKUjk=eH1IDUjmi′,Ppub⋅eg1mi′,g⋅eH2wi,PKUj′.


## 4.2.2. Type-II Attack Analysis

Like type-I attack, a type-II attacker also has the access to all public parameters, including the public keyPKUj of the victim user Uj, and a valid tuple mi,wi,σi for some i. In addition, it has the master secret key α in its possession. The attacker can execute the following steps to generate a forged tag σi′ for a forged data block mi′, keeping the authenticating information same as wi.(1)
Generates a forged data blockmi′ of its choice.(2)
CalculatesDUj=H1IDUjα.(3)
CalculatesX=DUj⋅g1mi(4)
CalculatesY=σi/X.(5)
Computes the forged tag asσi′=DUj⋅g1mi′.Y.(6)
The attacker outputs the tuplemi′,wi,σi′.Note that in the above attack, the attacker does not need access to the personal secret keyβUj of the victim user Uj. Also, it does not replace the original public key PKUj of the user.Lemma 2.
The forged tagσi′ generated using the above mechanism is a valid tag on the forged data block mi′ with authenticating information wi under the public values IDUj,PKUj of the victim user Uj.Proof.
Let us prove the lemma by showing the validity of the forged tuplemi′,wi,σi′ under the public key PKUj of user Uj, as per equation (2). The correctness proof is given below:(4)Y=σiX=DUj⋅g1miH2wiβUjDUj⋅g1mi=H2wiβUj,and hence(5)eσi′,g=eDUj⋅g1mi′⋅Y,g=eDUjmi′,g⋅eg1mi′,g⋅eY,g=eH1IDUjαmi′,g⋅eg1mi′,g⋅eH2wiβUj,g=eH1IDUjmi′,gα⋅eg1mi′,g⋅eH2wi,gβUj=eH1IDUjmi′,Ppub⋅eg1mi′,g⋅eH2wi,PKUj.


## 4.2.3. Remarks on the Analysis

The above analysis shows that if an attacker (type I or type II) obtains a valid data block and tag pairmi,σi corresponding to some block i of a data file Fid belonging to a victim user Uj, then it can replace the block by generating a valid tag σi′ for a forged block mi′ while keeping the authenticating information same as wi=Fidni. More importantly, we can also observe that the forged block mi′ 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. This 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 wi of a block with the public key of the user. This 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 tag-generation mechanism which is provably secure against both type-I and type-II attacks.


## 4.3. Brief Overview on the Tag-Generation Mechanism of the Scheme in [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.Tag-Gen. Using this algorithm, a group user Uj for 1≤j≤d generates tag for a block mi of the file M=m1,m2,…,mn with file identity Fid where n is the number of blocks, mi∈Zq∗. User Uj computes the tag σi as(6)σi=DUjmiH2wiβUj,where wi=i‖Fid. The partial private key is calculated as DUj=H1IDUj+ηα where α,η∈Zq∗ are secretly kept with the group manager, which acts as the KGC in this protocol. User Uj sends the message block and tag pair mi,σi to the cloud and updates a public log file with the values index i, the user public identity H1IDUj+η, and the user public key PUj=gβUj where βUj is secret to the user Uj.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.


## 5. 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.


### 5.1. Entities Involved

The proposed protocols consist of the following entities.The 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.The Cloud User Group. The cloud user is an edge device in our scheme. A group of edge devices forming a cluster constitutes a user group. There exists a group manager who manages the usual activities of a user group [72]. These 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.The 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.The 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.


### 5.2. Data Structures and Files

The 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 IDF, stored with the CSP and shared among d users (edge devices), can have n number of data blocks m1,m2,…,mn 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 S1,S2,…,Sn 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. The indicator matrix is a n×d 2D matrix whose each row corresponds to a block index i1≤i≤n and each column corresponds to an user u1≤u≤d. We use the notation Ii,u to denote Iiu which is defined as follows:(7)Ii,u=1,if useruis the generator of blocki,1,otherwise.Log-File-1. The data auditor maintains the Log-File-1. Corresponding to every data audit instance, there is an entry in this file. The fields contained in each entry are as shown below:(8)t,t′,IDF,Result,Signed Proof,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 IDF. 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. The CSP maintains Log-File-2 which contains the indicator matrix I for every data file. The auditor and all the cloud users have read access to Log-File-2.


### 5.3. Assumptions

We assume the existence of a scalable public blockchain, suited for FOG-CPS environments, inside the network. There are several works that have proposed scalable public blockchain techniques for FOG-CPSs [55–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. The auditor is supposed to invoke data auditing protocol as per the requirements specified in the SLA.


## 5.1. Entities Involved

The proposed protocols consist of the following entities.The 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.The Cloud User Group. The cloud user is an edge device in our scheme. A group of edge devices forming a cluster constitutes a user group. There exists a group manager who manages the usual activities of a user group [72]. These 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.The 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.The 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.


## 5.2. Data Structures and Files

The 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 IDF, stored with the CSP and shared among d users (edge devices), can have n number of data blocks m1,m2,…,mn 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 S1,S2,…,Sn 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. The indicator matrix is a n×d 2D matrix whose each row corresponds to a block index i1≤i≤n and each column corresponds to an user u1≤u≤d. We use the notation Ii,u to denote Iiu which is defined as follows:(7)Ii,u=1,if useruis the generator of blocki,1,otherwise.Log-File-1. The data auditor maintains the Log-File-1. Corresponding to every data audit instance, there is an entry in this file. The fields contained in each entry are as shown below:(8)t,t′,IDF,Result,Signed Proof,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 IDF. 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. The CSP maintains Log-File-2 which contains the indicator matrix I for every data file. The auditor and all the cloud users have read access to Log-File-2.


## 5.3. Assumptions

We assume the existence of a scalable public blockchain, suited for FOG-CPS environments, inside the network. There are several works that have proposed scalable public blockchain techniques for FOG-CPSs [55–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. The auditor is supposed to invoke data auditing protocol as per the requirements specified in the SLA.


## 6. 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 instantt, the latest hash-block is identified uniquely in the blockchain. This 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.The 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. This algorithm is executed by the KGC during the setup phase of the protocol. Steps of the algorithm are as follows.(1)
On inputk, the algorithm generates two cyclic multiplicative groups G1,G2 of prime order q and an admissible bilinear map e^:G1×G1⟶G2. KGC selects a random generator g∈G1.(2)
KGC chooses a randomα∈Zq∗ as the master-secret-key (msk) and sets Ppub=gα.(3)
KGC selects three secure hash functionsH1:0,1∗⟶G1, H2:0,1∗⟶G1, for partial-private-key and tag generation purposes, respectively, and H3:G2⟶Zq∗ for masking of data possession proof. The security analysis for the proposed scheme views H1 and H2 as random oracles.(4)
KGC selects another global hash function defined asΩ:0,1∗⟶0,12l. The function produces a 2l-bit binary string from a given hash-block of a blockchain. The 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:f:0,1l×Zn+1−0⟶Zq∗π:0,1l×Zn+1−0⟶Zn+1−0.The first input in both of the above two functions is anl-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)
The KGC publishes the public parametersparams=G1,G2,q,e^,g,Ppub,H1,H2,Ω,f,π.Partial-Private-Key-Extract. On receiving a request from user with identity IDu, KGC calculates Qu=H1IDu and Du=Quα and forwards the partial-private-key Du to the corresponding user through a secure channel.Set-Secret-Value. User with identity IDu randomly chooses βu∈Zq∗ and keeps it as a personal secret value.Private-Key-Gen. User with identity IDu sets the private key for itself as Du,βu.Set-Public-Key. User with identity IDu sets its public key as Pu=gβu. The 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. The steps followed by an user u to generate the encrypted tag-signature Ti on data block mi of a data file F are as shown below:(1)
Calculates the authenticating tag informationwi=IDFiPu for the block mi.(2)
Computes the tag-signatureSi for block mi as Si=DumiH2wiβu.(3)
Encrypts the tag using its shared secret keyKu with the CSP as Ti=EncrKuSi.(4)
Useru sends the data block mi along with the encrypted tag Ti to the CSP.(9)u⟶CSP:IDu,Pu,IDF,i,mi,Ti.The CSP extracts the tag-signatureSi by decrypting Ti using the shared secret key Ku. It calculates the authenticating tag information wi=IDFiPu and Qu=H1IDu and verifies the tag-signature by checking the following equality:(10)eSi,g=?eQumi,Ppub.eH2wi,Pu.Upon successful verification, the CSP updates the indicator matrixI corresponding to the data file F as Ii,u=1. It also stores the data block mi as the i′th block in the data file F and the tag Si 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 c1≤c≤n as the size of the challenge vector and sends the challenge request as chal=t,c,IDF to the CSP, where t is the instant in time when the audit gets performed.(11)Auditor⟶CSP:t,c,IDF.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 k1,k2∈0,1l from the retrieved hash-block using the global function Ω. The CSP computes the set C=i,vi, where i=πk1,x and vi=fk2,x for 1≤x≤c. Next, it computes proof of possession for the challenged blocks as follows.For each useru∈1,…,d, the CSP computes μu and σu as follows:(12)μu=∑i∈CvimiIi,u,σu=∏i∈CSiviIi,u.CSP setsμ=μ1,μ2,…μd and σ=σ1,σ2,…σd and generates the data possession proof as P=σ,μ. Finally, the CSP signs the generated proof P with its private key using the certificateless signature mechanism and sends the signed proof to the auditor.(13)CSP⟶Auditor:P=σ,μ,SigCSPP.Proof-Ver. The auditor verifies the received proof in the following way:(1)
The auditor first verifies the signatureSigCSPP 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 timet from the public blockchain. The retrieved hash-block is used to extract the random values k1,k2∈0,1l using the global function Ω.(3)
The auditor calculates the public valueQu=H1IDu;∀u∈1,…,d of the users. Then, it aggregates the values in σ,μ, respectively, as σπ=∏u=1dσu and μπ=∏u=1dQuμu.(4)
The auditor computes the challenge vectorsC=i,vi, where i=πk1,x and vi=fk2,x for all 1≤x≤c.(5)
For eachi∈C, the auditor retrieves the public key information for user u such that Ii,u=1 and calculates the authenticating tag information wi=IDFiPu.(6)
Auditor accepts the proof as valid only if the following equality holds:(14)eσπ,g=?eμπ,Ppub.∏u=1de∏i∈CH2wiviIi,u,Pu.Once the verification of the received proofP is done, the data auditor creates a report-message of the form Report=t,IDF,Result,Signed Proof where t is the instant of time used in the challenge message, IDF 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,SigCSPP. The auditor submits the hash digest of the Report message along with its identity to the public blockchain. The 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′,IDF,Result,Signed Proof in Log-File-1 where the values of t,IDF,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. The correctness proof is given below.(15)eσu,g=e∏i∈CSiviIi,u,g=∏i∈CeSi,gviIi,u=∏i∈CeQumi,PpubviIi,u∏i∈CeH2wi,PuviIi,u.(from equation (10))(16)=eQu∑i∈CmiviIi,u,Ppub.e∏i∈CH2wiviIi,u,Pu=eQuμu,Ppub.e∏i∈CH2wiviIi,u,Pu.
Hence,(17)eσπ,g=e∏u=1dσu,g=∏u=1deσu,g=∏u=1deQuμu,Ppub∏u=1de∏i∈CH2wiviIi,u,Pu=eμπ,Ppub.∏u=1de∏i∈CH2wiviIi,u,Pu.
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.


## 7. 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. The 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 protectdata 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 privacy-preserving auditing (CRPPA) protocol for shared data auditing in FOG-CPSs.


### 7.1. 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.


#### 7.1.1. 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. The 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. This should be ensured even when the number of such interactions is very large. This security requirement is analogous to the requirement in azero-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.


#### 7.1.2. Type-V Adversary (Adv5)

Security of an RDIC protocol against a type-III attacker (Section3.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. This 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. The 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. The 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.


#### 7.1.3. 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 verifytimeliness 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. Table2 summarizes the six types of attack scenarios, the entities involved in the attack, the objective of the attack, and the method of attack.Table 2
Types of attack scenarios.
Entities involved in the attackObjective of the attackMethod of the attackAttack type first introducedType-ICompromised usersImpersonating a legitimate userGenerate forged tag by replacing public keyAl-Riyami et al. [45]Type-IICompromised but passive KGCImpersonating a legitimate userGenerate forged tag without replacing public keyAl-Riyami et al. [45]Type-IIICompromised CSPSuppress data loss/corruption eventGenerate forged data possession proof (without storing the data file properly)Ateniese et al. [9]Type-IVCompromised data auditorExtract confidential data and/or metadata of the usersPerforming cryptanalysis on the challenge-response messagesWang et al. [75]Type-VCollusion of data auditor and CSPSuppress data loss/corruption eventDisclosing the random challenge vectors in advance to the CSPArmknecht et al. [48]Type-VICompromised data auditorSave computational resources (selfish behaviour)Skipping or delaying the auditing tasksZhang et al. [25]


### 7.2. Construction of the Proposed CRPPA Protocol

The proposed certificateless reliable privacy-preserving auditing (CRPPA) protocol for shared data auditing in FOG-CPSs consists of a total of ten algorithms. The 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. The 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. The 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 k1,k2 using the global function Ω from the public blockchain as described in the proposed basic CLS-RDIC scheme. The CSP computes proof of possession for the challenged blocks as follows.The CSP setsC=i,vi, where i=πk1,x and vi=fk2,x for 1≤x≤c.For each useru∈1,…,d,(1)
The CSP computes the public valueQu=H1IDu and selects three random values rmu←RZq∗,rσu←RZq∗,ρu←RZq∗, which are used for masking the σ and μ values.(2)
CSP calculatesRu=eQu,Ppubrmu⋅eg1,grσu and γu=H3Ru.(3)
CSP generatesμu,σu as follows:(18)μu=∑i∈CvimiIi,u,σu=∏i∈CSiviIi,u.(4)
Next, CSP calculatesμu′=rmu+γuμu, Σu=σu⋅g1ρu, and εu=rσu+γuρu. The masking of σ,μ helps to provide zero-knowledge data privacy against the auditor.(5)
The CSP calculates the integrity proof asP=μ′,Σ,ε,R where μ′=μ1′,μ2′,…,μd′, Σ=Σ1,Σ2,…,Σd, ε=ε1,ε2,…,εd, R=R1,R2,…,Rd.Finally, the CSP signs the generated proofP with its private key using the certificateless signature mechanism and sends the signed proof to the auditor.(19)CSP⟶Auditor:P=μ′,Σ,ε,R,SigCSPP.Proof-Ver. The auditor first checks if SigCSPP 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)
The auditor retrieves the hash-block corresponding to timet from the public blockchain. The retrieved hash-block is used to extract the random values k1,k2∈0,1l using the global function Ω.(2)
For each useru∈1,2,…,d, the auditor calculates γu=H3Ru.(3)
The auditor aggregates the values in the received proofP=μ′,Σ,ε,R as Rπ=∏u=1dRu, Σπ=∏u=1dΣuγu, μπ′=∏u=1dQuμu′, and επ=∑u=1dεu.(4)
The auditor generates the challenge vectorsC=i,vi, where i=πk1,x and vi=fk2,x for all 1≤x≤c.(5)
For eachi∈C, the auditor gets public key information of user u such that Ii,u=1 and calculates the authenticating tag information wi=IDFiPu.(6)
The auditor accepts the proof only if the following equation holds correct.(20)Rπ⋅eΣπ,g=?∏u=1de∏i∈CH2wiviIi,uγu,Pu⋅eμπ′,Ppub⋅eg1,gεπ.Once the verification of the received proofP is done, the data auditor creates a report-message of the form Report=t,IDF,Result,Signed Proof where t is the instant of time used in the challenge message, IDF 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,SigCSPP. The auditor submits the hash digest of the Report message along with its identity to the public blockchain. The 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′,IDF,Result,Signed Proof in Log-File-1 where the values of t,IDF,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. The correctness proof is given below.(21)Ru⋅eΣuγu,g=eQu,Ppubrmu⋅eg1,grσu⋅eσu⋅g1ρuγu,g=eQu,Ppubrmu⋅eg1,grσu⋅eSiviIi,u⋅g1ρuγu,g=eQu,Ppubrmu⋅eg1,grσu⋅eQu,Ppubγuμu⋅e∏i∈CH2wiviIi,uβuγu,geg1γuρu,g=eQuμu′,Ppub⋅eg1,gεu⋅e∏i∈CH2wiviIi,uγu,Pu.
Hence,(22)Rπ⋅eΣπ,g=∏u=1dRu⋅e∏u=1dΣuγu,g=∏u=1dRu⋅eΣuγu,g=∏u=1deQuμu′,Ppub⋅eg1εu,g⋅e∏i∈CH2wiviIi,uγu,Pu=eμπ′,Ppub⋅eg1,gεπ⋅∏u=1de∏i∈CH2wiviIi,uγu,Pu.
Verify-Proof. In order to audit data file F, an audit-verifier first chooses an audit-interval T=T1,T2 from the past and retrieves all the entries from Log-File-1 where the audit instance t lies in the interval T and the IDF 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 notationSigned Prooft to denote the signed proof at audit instance t∈T. Hence, Signed Prooft≡Pt,SigCSPPt where Pt=μ′t,Σt,εt,Rt, and(23)μ′t=μ1′t,μ2′t,…,μd′t,Σt=Σ1t,Σ2t,…,Σdt,εt=ε1t,ε2t,…,εdt,Rt=R1t,R2t,…,Rdt.(1)
For each audit instancet∈T, the audit-verifier performs the following:(i)
Checks the validity of the signatureSigCSPPt using the public key of the CSP. It proceeds only if the signature is valid.(ii)
Calculatesγut=H3Rut, for all u∈1,2,…,d.(iii)
CalculatesCt=i,vi, where i=πk1t,x and vi=fk2t,x, for all 1≤x≤c, where k1t and k2t are the random strings extracted using the global function Ω from the hash-blocks at time instant t of the public blockchain.(iv)
The audit-verifier computes the following aggregates values for the audit instancet:(24)μπ′t=∏u=1dQuμu′t,Σπt=∏u=1dΣutγut,επt=∑u=1dεut,Rπt=∏u=1dRut.(2)
Finally, the audit-verifier computes the following aggregate values by aggregating the above aggregate values for allt∈T:(25)μagg′=∏∀t∈Tμπ′t,Σagg=∏∀t∈TΣπt,εagg=∑∀t∈Tεπt,Ragg=∏∀t∈TRπt,Cagg=∪∀t∈TCt.(3)
For alli∈Cagg, the verifier retrieves the public key Pu of user u such that Ii,u=1 and calculates the authenticating tag information as wi=IDFiPu.(4)
The audit verification results in a success only if the following equality holds:(26)Ragg⋅eΣagg,g=?∏∀t∈T∏u=1de∏i∈CtH2wiviIi,uγut,Pu⋅eμagg¢′,Ppub⋅eg1,gεagg.Lemma 5.
If the data auditor performs all the proof verifications honestly for each audit instancet∈T, then the above-mentioned aggregate audit verification must result in success.Proof.
The above-mentioned aggregate audit verification is initiated only when theResult field in each entry corresponding to each audit instance t∈T shows 1, in the Log-File-1. This 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.,(27)Rπt⋅eΣπt,g=?∏u=1de∏i∈CtH2wiviIi,uγut,Pu⋅eμπ′t,Ppub⋅eg1,gεπt.
Let us take the product of the left-hand side (LHS) of the above equation for allt∈T:(28)∏∀t∈TLHS=∏∀t∈TRπt⋅eΣπt,g=∏∀t∈TRπt⋅∏∀t∈TeΣπt,g=∏∀t∈TRπt⋅e∏∀t∈TΣπt,g=Ragg⋅eΣagg,g.
Similarly, we take the product of the right-hand side (RHS) of equation (27) for all t∈T:-(29)∏∀t∈TRHS=∏∀t∈T∏u=1de∏i∈CtH2wiviIi,uγut,Pu⋅∏∀t∈Teμπ′t,Ppub⋅∏∀t∈Teg1,gεπt=∏∀t∈T∏u=1de∏i∈CtH2wiviIi,uγut,Pu⋅e∏∀t∈Tμπ′t,Ppub⋅eg1,g∑∀t∈Tεπt=∏∀t∈T∏u=1de∏i∈CtH2wiviIi,uγut,Pu⋅eμagg′,Ppub⋅eg1,gεagg.
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. The 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 instancet∈T, the audit-verifier constructs a Report message the same way as it is mentioned in the Proof-Ver algorithm, i.e., Report=t,IDF,Result,SignedProof. The 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 theVerify-Proof algorithm has been analyzed in the next section.


## 7.1. 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.


### 7.1.1. 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. The 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. This should be ensured even when the number of such interactions is very large. This security requirement is analogous to the requirement in azero-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.


### 7.1.2. Type-V Adversary (Adv5)

Security of an RDIC protocol against a type-III attacker (Section3.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. This 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. The 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. The 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.


### 7.1.3. 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 verifytimeliness 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. Table2 summarizes the six types of attack scenarios, the entities involved in the attack, the objective of the attack, and the method of attack.Table 2
Types of attack scenarios.
Entities involved in the attackObjective of the attackMethod of the attackAttack type first introducedType-ICompromised usersImpersonating a legitimate userGenerate forged tag by replacing public keyAl-Riyami et al. [45]Type-IICompromised but passive KGCImpersonating a legitimate userGenerate forged tag without replacing public keyAl-Riyami et al. [45]Type-IIICompromised CSPSuppress data loss/corruption eventGenerate forged data possession proof (without storing the data file properly)Ateniese et al. [9]Type-IVCompromised data auditorExtract confidential data and/or metadata of the usersPerforming cryptanalysis on the challenge-response messagesWang et al. [75]Type-VCollusion of data auditor and CSPSuppress data loss/corruption eventDisclosing the random challenge vectors in advance to the CSPArmknecht et al. [48]Type-VICompromised data auditorSave computational resources (selfish behaviour)Skipping or delaying the auditing tasksZhang et al. [25]


## 7.1.1. 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. The 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. This should be ensured even when the number of such interactions is very large. This security requirement is analogous to the requirement in azero-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.


## 7.1.2. Type-V Adversary (Adv5)

Security of an RDIC protocol against a type-III attacker (Section3.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. This 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. The 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. The 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.


## 7.1.3. 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 verifytimeliness 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. Table2 summarizes the six types of attack scenarios, the entities involved in the attack, the objective of the attack, and the method of attack.Table 2
Types of attack scenarios.
Entities involved in the attackObjective of the attackMethod of the attackAttack type first introducedType-ICompromised usersImpersonating a legitimate userGenerate forged tag by replacing public keyAl-Riyami et al. [45]Type-IICompromised but passive KGCImpersonating a legitimate userGenerate forged tag without replacing public keyAl-Riyami et al. [45]Type-IIICompromised CSPSuppress data loss/corruption eventGenerate forged data possession proof (without storing the data file properly)Ateniese et al. [9]Type-IVCompromised data auditorExtract confidential data and/or metadata of the usersPerforming cryptanalysis on the challenge-response messagesWang et al. [75]Type-VCollusion of data auditor and CSPSuppress data loss/corruption eventDisclosing the random challenge vectors in advance to the CSPArmknecht et al. [48]Type-VICompromised data auditorSave computational resources (selfish behaviour)Skipping or delaying the auditing tasksZhang et al. [25]


## 7.2. Construction of the Proposed CRPPA Protocol

The proposed certificateless reliable privacy-preserving auditing (CRPPA) protocol for shared data auditing in FOG-CPSs consists of a total of ten algorithms. The 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. The 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. The 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 k1,k2 using the global function Ω from the public blockchain as described in the proposed basic CLS-RDIC scheme. The CSP computes proof of possession for the challenged blocks as follows.The CSP setsC=i,vi, where i=πk1,x and vi=fk2,x for 1≤x≤c.For each useru∈1,…,d,(1)
The CSP computes the public valueQu=H1IDu and selects three random values rmu←RZq∗,rσu←RZq∗,ρu←RZq∗, which are used for masking the σ and μ values.(2)
CSP calculatesRu=eQu,Ppubrmu⋅eg1,grσu and γu=H3Ru.(3)
CSP generatesμu,σu as follows:(18)μu=∑i∈CvimiIi,u,σu=∏i∈CSiviIi,u.(4)
Next, CSP calculatesμu′=rmu+γuμu, Σu=σu⋅g1ρu, and εu=rσu+γuρu. The masking of σ,μ helps to provide zero-knowledge data privacy against the auditor.(5)
The CSP calculates the integrity proof asP=μ′,Σ,ε,R where μ′=μ1′,μ2′,…,μd′, Σ=Σ1,Σ2,…,Σd, ε=ε1,ε2,…,εd, R=R1,R2,…,Rd.Finally, the CSP signs the generated proofP with its private key using the certificateless signature mechanism and sends the signed proof to the auditor.(19)CSP⟶Auditor:P=μ′,Σ,ε,R,SigCSPP.Proof-Ver. The auditor first checks if SigCSPP 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)
The auditor retrieves the hash-block corresponding to timet from the public blockchain. The retrieved hash-block is used to extract the random values k1,k2∈0,1l using the global function Ω.(2)
For each useru∈1,2,…,d, the auditor calculates γu=H3Ru.(3)
The auditor aggregates the values in the received proofP=μ′,Σ,ε,R as Rπ=∏u=1dRu, Σπ=∏u=1dΣuγu, μπ′=∏u=1dQuμu′, and επ=∑u=1dεu.(4)
The auditor generates the challenge vectorsC=i,vi, where i=πk1,x and vi=fk2,x for all 1≤x≤c.(5)
For eachi∈C, the auditor gets public key information of user u such that Ii,u=1 and calculates the authenticating tag information wi=IDFiPu.(6)
The auditor accepts the proof only if the following equation holds correct.(20)Rπ⋅eΣπ,g=?∏u=1de∏i∈CH2wiviIi,uγu,Pu⋅eμπ′,Ppub⋅eg1,gεπ.Once the verification of the received proofP is done, the data auditor creates a report-message of the form Report=t,IDF,Result,Signed Proof where t is the instant of time used in the challenge message, IDF 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,SigCSPP. The auditor submits the hash digest of the Report message along with its identity to the public blockchain. The 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′,IDF,Result,Signed Proof in Log-File-1 where the values of t,IDF,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. The correctness proof is given below.(21)Ru⋅eΣuγu,g=eQu,Ppubrmu⋅eg1,grσu⋅eσu⋅g1ρuγu,g=eQu,Ppubrmu⋅eg1,grσu⋅eSiviIi,u⋅g1ρuγu,g=eQu,Ppubrmu⋅eg1,grσu⋅eQu,Ppubγuμu⋅e∏i∈CH2wiviIi,uβuγu,geg1γuρu,g=eQuμu′,Ppub⋅eg1,gεu⋅e∏i∈CH2wiviIi,uγu,Pu.
Hence,(22)Rπ⋅eΣπ,g=∏u=1dRu⋅e∏u=1dΣuγu,g=∏u=1dRu⋅eΣuγu,g=∏u=1deQuμu′,Ppub⋅eg1εu,g⋅e∏i∈CH2wiviIi,uγu,Pu=eμπ′,Ppub⋅eg1,gεπ⋅∏u=1de∏i∈CH2wiviIi,uγu,Pu.
Verify-Proof. In order to audit data file F, an audit-verifier first chooses an audit-interval T=T1,T2 from the past and retrieves all the entries from Log-File-1 where the audit instance t lies in the interval T and the IDF 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 notationSigned Prooft to denote the signed proof at audit instance t∈T. Hence, Signed Prooft≡Pt,SigCSPPt where Pt=μ′t,Σt,εt,Rt, and(23)μ′t=μ1′t,μ2′t,…,μd′t,Σt=Σ1t,Σ2t,…,Σdt,εt=ε1t,ε2t,…,εdt,Rt=R1t,R2t,…,Rdt.(1)
For each audit instancet∈T, the audit-verifier performs the following:(i)
Checks the validity of the signatureSigCSPPt using the public key of the CSP. It proceeds only if the signature is valid.(ii)
Calculatesγut=H3Rut, for all u∈1,2,…,d.(iii)
CalculatesCt=i,vi, where i=πk1t,x and vi=fk2t,x, for all 1≤x≤c, where k1t and k2t are the random strings extracted using the global function Ω from the hash-blocks at time instant t of the public blockchain.(iv)
The audit-verifier computes the following aggregates values for the audit instancet:(24)μπ′t=∏u=1dQuμu′t,Σπt=∏u=1dΣutγut,επt=∑u=1dεut,Rπt=∏u=1dRut.(2)
Finally, the audit-verifier computes the following aggregate values by aggregating the above aggregate values for allt∈T:(25)μagg′=∏∀t∈Tμπ′t,Σagg=∏∀t∈TΣπt,εagg=∑∀t∈Tεπt,Ragg=∏∀t∈TRπt,Cagg=∪∀t∈TCt.(3)
For alli∈Cagg, the verifier retrieves the public key Pu of user u such that Ii,u=1 and calculates the authenticating tag information as wi=IDFiPu.(4)
The audit verification results in a success only if the following equality holds:(26)Ragg⋅eΣagg,g=?∏∀t∈T∏u=1de∏i∈CtH2wiviIi,uγut,Pu⋅eμagg¢′,Ppub⋅eg1,gεagg.Lemma 5.
If the data auditor performs all the proof verifications honestly for each audit instancet∈T, then the above-mentioned aggregate audit verification must result in success.Proof.
The above-mentioned aggregate audit verification is initiated only when theResult field in each entry corresponding to each audit instance t∈T shows 1, in the Log-File-1. This 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.,(27)Rπt⋅eΣπt,g=?∏u=1de∏i∈CtH2wiviIi,uγut,Pu⋅eμπ′t,Ppub⋅eg1,gεπt.
Let us take the product of the left-hand side (LHS) of the above equation for allt∈T:(28)∏∀t∈TLHS=∏∀t∈TRπt⋅eΣπt,g=∏∀t∈TRπt⋅∏∀t∈TeΣπt,g=∏∀t∈TRπt⋅e∏∀t∈TΣπt,g=Ragg⋅eΣagg,g.
Similarly, we take the product of the right-hand side (RHS) of equation (27) for all t∈T:-(29)∏∀t∈TRHS=∏∀t∈T∏u=1de∏i∈CtH2wiviIi,uγut,Pu⋅∏∀t∈Teμπ′t,Ppub⋅∏∀t∈Teg1,gεπt=∏∀t∈T∏u=1de∏i∈CtH2wiviIi,uγut,Pu⋅e∏∀t∈Tμπ′t,Ppub⋅eg1,g∑∀t∈Tεπt=∏∀t∈T∏u=1de∏i∈CtH2wiviIi,uγut,Pu⋅eμagg′,Ppub⋅eg1,gεagg.
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. The 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 instancet∈T, the audit-verifier constructs a Report message the same way as it is mentioned in the Proof-Ver algorithm, i.e., Report=t,IDF,Result,SignedProof. The 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 theVerify-Proof algorithm has been analyzed in the next section.


## 8. Security Analysis

### 8.1. 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 Section8.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 Theorems 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 Theorem 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.The 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 inG1 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 G1. Suppose Adv1 makes at most q1H1 hash queries, q2 partial-private-key queries, q3 secret-value queries, q4 public-key queries, q5 public-key-replace queries, q6H2 hash queries, and q7 tag-gen queries, where q1,q2,q3,q4,q5,q6,q7 all are in polynomialk; then, the success probability, ξ′k, of challenger C in solving the above problem is lower bounded by(30)ξ′k≥ξke⋅1+q2+q7,where e≈2.71828 is the base of the natural logarithm. In addition, the time complexity classes are OC≈OAdv1+Oq1+q2+q3+q4+q5+q6+q7.Proof.
Let Adv1 be the adversary as in game-1 who is capable of forging a tag. Then, we construct a simulatorC using Adv1 as subroutine to solve the CDH problem in G1. C simulates game-1 in the following way.
Setup. Given a CDH problem instance q,G1,g,h1,h2, h1=gα, for some α∈Zq∗. C chooses another cyclic multiplicative group G2, G1=G2=q, and an admissible bilinear map e^=G1×G1⟶G2. C sets the public parameters params=G1,G2,q,e^,g,Ppub=h1,H1,H2 and sends params to Adv1. Note that the master secret key(α) is unknown to the challenger C.
H1Hash Query. Adv1 adaptively queries for H1 for any identity IDu. For every H1 query, C maintains a list H1-List=IDu,Qu,ru,Su,Pu,bu. If the IDu is already queried before, C simply retrieves the tuple from the H1-List and returns Qu to Adv1. If IDu is new, C randomly picks ru∈Zq∗ and tosses a coin bu∈0,1, where the probability of bu=0 is φ and that of bu=1 is 1−φ. If bu=0, then C sets Qu=gru, chooses a random value βu∈Zq∗, and sets Su=βu and Pu=gβu. Else if bu=1, then C sets Qu=h2⋅gru, chooses a random value βu∈Zq∗, and sets Su=βu and Pu=gβu. Finally, C inserts the values IDu,Qu,ru,Su,Pu,bu into H1-List. Return Qu to Adv1.
Partial-Private-Key Query. Adv1 adaptively queries for partial-private-key for any identity IDu. C scans for IDu in H1-List. If IDu does not exist in H1-List, C queries itself for H1IDu. If bu=0, then retrieve ru from H1-List set Du=h1ru and return Du to Adv1. Else if bu=1, then abort.
Secret-Value Query. Adv1 adaptively queries for set-secret-value for any identity IDu. C scans for IDu in H1-List. If IDu does not exist in H1-List, C queries itself for H1IDu. If Su=⊥, C chooses a random value βu∈Zq∗ and sets Su=βu and Pu=gβu. C updates the values Su,Pu into H1-List and returns Su to Adv1.
Public-Key Query. Adv1 adaptively queries for public-key for any identity IDu. C scans for IDu in H1-List. If IDu does not exist in H1-List, C queries itself for H1IDu. C retrieves Pu and returns it to Adv1.
Public-Key-Replace Query. Adv1 adaptively queries for a public-key replacement for any identity IDu with IDu,Pu′. C scans for IDu in H1-List. If IDu does not exist in H1-List, C queries itself for H1IDu. C sets Su=⊥ and Pu=Pu′ and updates H1-List.
H2Hash Query. Adv1 adaptively queries for wk,Pu. For every H2 query, C maintains a list H2-List=wk,Hk2,rk,Pu. C scans H2-List for wk,Pu. If wk,Pu does not exist in H2-List, C randomly chooses rk∈Zq∗, sets Hk2=grk, and updates H2-List. C returns Hk2 to Adv1.
Tag-Gen Query. Adv1 adaptively queries with the values m,wk,IDu. If IDu does not exist in H1-List, C queries itself for H1IDu. C retrieves Pu from H1-List. If bu=0, then, C queries for Du. C scans for wk,Pu in H2-List, and if it exists, then retrieve Hk2; else, C self-queries for Hk2 with the values wk,Pu. Now C retrieves Su from H1-List for IDu. It computes tag σ=Dum⋅Hk2Su. Else if bu=1 and wk,Puexists in H2-List, then abort. Else select randomly rk∈Zq∗, compute Hk2=grk⋅h1−m, set Pu=h2, compute σ=h1rum⋅h2rk, and finally insert the tuple wk,Hk2,⊥,Pu to H2-List. C returns σ to Adv1
Forge-Tag. Adv1 outputs a tuple σ′,m′,wk′,IDu′,Pu′, where σ′ is the forged tag on the message m′ with authenticating information wk′ for identity IDu′ with public key Pu′.
Analysis. If Adv1 successfully forges the tag, then the tuple should be valid. If bu=0, then C aborts. Else if bu=1, C uses the following verification equation: eσ′,g=eH1IDu′m′,Ppub⋅eH2wk′,Pu′,Pu′. C retrieves the tuple from H1-List for the forged IDu′, and C retrieves the value of Qu=h2⋅gru from H1-List and H2wk′,Pu′=grk′ from H2-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,h1=gα,h2), C calculates h2α as follows.
As per the verification equation:(31)eσ′,g=eh2⋅grum,Ppub⋅egrk′,Pu′,eσ′,g=eh2α⋅m′⋅gαru⋅m′,g⋅ePu′rk′,g,h2α=σ′Pu′rk′⋅h1ru⋅m′1/m′.
We now calculate the minimum success probabilityξ′k with which the challenger C can solve an instance of the given CDH problem in G1. For this to happen, the challenger C must not abort during the above simulation. There 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. The partial-private-key query phase and the tag-gen query phase do not abort when bu=0, whereas the analysis phase does not abort when bu=1. Hence, the probability that the challenger C does not abort the above simulation is 1−φ⋅φq2+q7. The quantity 1−φ⋅φq2+q7 is maximized when φ=φmax=q2+q7/1+q2+q7. 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+q2+q7. Hence, the minimum success probability with which the challenger C can solve an instance of the given CDH problem is ξ′k≥ξk/e⋅1+q2+q7. It can be noted that since q2 and q7 are polynomialk, the quantity 1/1+q2+q7 is non-negligible. Thus, if ξk is non-negligible, then the success probability ξ′k is also non-negligible.
The running time ofC 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., H1 hash query t1, partial-private-key query t2, secret-value query t3, public-key query t4, public-key-replace query t5, H2 hash query t6, and tag-gen query t7 executed q1,q2,q3,q4,q5,q6, and q7 times, respectively. Therefore, OC=OAdv1+Oq1⋅t1+q2⋅t2+q3⋅t3+q4⋅t4+q5⋅t5+q6⋅t6+q7⋅t7. Now since all the algorithms used in the simulation of challenger C are polynomial-time computable, OC=OAdv1+Oq1+q2+q3+q4+q5+q6+q7. It can be noted that q1,q2,q3,q4,q5,q6, and q7 all are in polynomialk. Therefore, OC≈OAdv1. It can be observed that if Adv1 is a polynomial-time algorithm, then the simulated CDH problem solver C is also a polynomial-time algorithm.
The 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 inG1 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 G1. Suppose Adv2 makes at most q1H1 hash queries, q2 secret-value queries, q3 public-key queries, and q4H2 hash queries, where q1,q2,q3, and q4 all are in polynomialk; then, the success probability, ξ′k, of challenger C in solving the above problem is lower bounded by(32)ξ′k≥ξke⋅1+q2,where e≈2.71828 is the base of the natural logarithm. In addition, the time complexity classes are OC≈OAdv2+Oq1+q2+q3+q4.Proof.
Let Adv2 be the adversary as in game-2 who is capable of forging a tag. Then, we construct an adversaryC using Adv2 as subroutine to solve the CDH problem in G1. C simulates game-2 in the following way.
Setup. Given an instance of CDH problem (g,G1,h1=gα,h2). C randomly picks s∈Zq∗, chooses another cyclic multiplicative group G2, G1=G2=q, and an admissible bilinear map e^:G1×G1⟶G2, and sets the public parameters params=G1,G2,q,e^,g,Ppub=gs,H1,H2. C sends params and s to Adv2, and s is the master secret key.
H1Hash Query. Adv2 adaptively queries for H1 for any identity IDu. For every H1 query, C maintains a list H1-List=IDu,Qu,ru,Su,Pu. If the IDu is already queried before, C simply retrieves the tuple from the H1-List and returns Qu to Adv2. If IDu is new, C randomly picks ru,βu∈Zq∗, sets Qu=gru, and tosses a coin bu∈0,1, where the probability of bu=0 is φ and that of bu=1 is 1−φ . If bu=0, then C sets Pu=gβu and Su=βu. Else if bu=1, then C sets Pu=h1βu and Su=⊥. Finally, C inserts the values IDu,Qu,ru,Su,Pu into H1-List. C returns Qu to Adv2.
Secret-Value Query. Adv2 adaptively queries for set-secret-value for any identity IDu. C scans for IDu in H1-List. If IDu does not exist, C queries itself for H1IDu. If bu=1, abort; else, C retrieves Su and returns it to Adv2.
Public-Key Query. Adv2 adaptively queries for public-key for any identity IDu. C scans for IDu in H1-List. If IDu does not exist, C queries itself for H1IDu. C retrieves Pu and returns it to Adv2.
H2Hash Query. Adv2 adaptively queries for wk,Pu. For every H2 query, C maintains a list H2-List=wk,Hk2,rk,Pu. C scans H2-List for wk,Pu. If wk,Pu does not exist, C randomly chooses rk∈Zq∗, sets Hk2=h2rk, and updates H2-List. C retrieves Hk2 and returns it to Adv2.
Forge-Tag. Adv2 outputs a tuple σ′,m′,wk′,IDu′,Pu′, where σ′ is the forged tag on the message m′ with authenticating information wk′ for identity IDu′ with public key Pu′.
Analysis. If Adv2 successfully forges the tag, then the tuple should be valid. If bu=0, then C aborts. Else if bu=1, C uses the following verification equation: eσm′,g=eH1IDu′m′,Ppub⋅eH2wk′,Pu′,Pu′. C retrieves the tuple from H1-List for the forged IDu′, and C retrieves the value of Qu=gru from H1-List and H2wk′,Pu′=h2rk′ from H2-List.
As per the verification equation:(33)eσ′,g=egru′⋅m′,Ppub⋅eh2rk′,gα⋅βu,eσ′,g=egru′⋅m′⋅s,g⋅eh2rk′⋅α⋅βu,g,h2α=σ′gru′⋅m′⋅s1/rk′⋅βu.
We now calculate the minimum success probabilityξ′k with which the challenger C can solve an instance of the given CDH problem in G1. For this to happen, the challenger C must not abort during the above simulation. There are two phases in the simulation where the challenger C can abort, i.e., in secret-value query phase and analysis phase. The secret-value query phase does not abort when bu=0, whereas the analysis phase does not abort when bu=1. Hence, the probability that the challenger C does not abort the above simulation is 1−φ⋅φq2. The quantity 1−φ⋅φq2 is maximized when φ=φmax=q2/1+q2. 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+q2. Hence, the minimum success probability with which the challenger C can solve an instance of the given CDH problem is ξ′k≥ξk/e⋅1+q2. It can be noted that since q2 is polynomialk, the quantity 1/1+q2 is non-negligible. Thus, if ξk is non-negligible, then the success probability ξ′k is also non-negligible.
The running time ofC 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., H1 hash query t1, secret-value query t2, public-key query t3, and H2 hash query t4 executed q1,q2,q3, and q4, times respectively. Therefore, OC=OAdv2+Oq1⋅t1+q2⋅t2+q3⋅t3+q4⋅t4. Now since all the algorithms used in the simulation of challenger C are polynomial-time computable, OC=OAdv2+Oq1+q2+q3+q4. It can noted that q1,q2,q3, and q4 all are in polynomialk. Therefore, OC≈OAdv2. 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.
The 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 inG1 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 G1. Suppose Adv3 makes at most q1H1 hash queries, q2 data-block queries, q3 public-key queries, and q4 tag-gen and H2 queries, where q1,q2,q3,q4 all are in polynomialk; then, the success probability, ξ′k, of challenger C in solving the above problem is lower bounded by(34)ξ′k≥ξk⋅1−1q,where q is the order of the group G1. In addition, the time complexity classes are OC≈OAdv3+Oq1+q2+q3+q4.Proof.
Let Adv3 be the adversary as in game-3 who is capable of generating a valid data possession proof for the challenged blocks. Then, we construct a PPT simulatorC using Adv3 as subroutine to solve either the DH or the CDH problem in G1. C simulates game-3 in the following way.
Setup. Given an instance of CDH problem g,G1,h1=ga,h2=gb and an instance of the DL problem g,G1,h2=gb. C chooses another cyclic multiplicative group G2, where G1=G2=q, and an admissible bilinear map e^:G1×G1⟶G2, sets the public parameters params=G1,G2,q,e^,g,Ppub=h1, and sends params to Adv3, and a and b are unknown to C.
H1Hash Query. Adv3 adaptively queries for H1 for any identity IDu. For every H1 query, C maintains a list H1-List=IDu,Qu,ru,βu,Pu. If IDu is already queried before, C simply retrieves the tuple from the H1-List and returns Qu to Adv3. If IDu is new, C randomly picks ru,βu∈Zq∗ and sets Qu=gruh2βu and Pu=h2βu. Finally, it inserts the values IDu,Qu,ru,βu,Pu into H1-List. C returns Qu to Adv3.
Data-Block Query. The file F=m1,…,mn with file identifier IDF 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. Then, C retrieves corresponding data block from the date file IDF and forwards to Adv3.
Public-Key Query. Adv3 adaptively queries for the public key of any identity IDu. C scans for IDu in H1-List, and if IDu does not exist, C queries itself for H1IDu. C retrieves Pu and returns it to Adv3.
Tag-Gen Query andH2Query. C maintains a list H2′-List=i,bi,H2IDFiPu,σi and computes tag for each index in IDF corresponding to user u shown in indicator matrix I as follows.
C randomly picks bi∈Zq∗, for i∈1,…,n. For each index i, C computes H2IDFiPu=gbih1−mi and σi=h1rumi⋅h2biβu, where βu and ru are retrieved from H1-List corresponding to Pu.
The validity of the tag simulation can be verified as follows.
As per the tag-gen algorithm,σi=DumiH2IDFiPubβu.
As per simulation,σi=Quamigbih1−mibβu.
By replacing value ofQu, σi=gru⋅h2βuami⋅gbbiβu⋅h1−bmiβu.
By replacing values ofh1,h2, σi=garumi⋅gabmiβu⋅gbbiβu⋅g−abmiβu.
σi=garumi⋅gbbiβu=h1rumi⋅h2biβu.
C adds the following tuple to its list H2′-List=i,bi,H2IDFiPu,σi. C sends σ1,...,σn, corresponding file F=m1,…,mn and indicator matrix Ii,u to Adv3.
Challenge. C chooses a number c (1≤c≤n) as the size of the challenge vector and two random values k1,k2∈0,1l 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,C=i,vi,IDF to the Adv3, where i=πk1,x, vi=fk2,x for 1≤x≤c.
Forge-Proof. Eventually Adv3 outputs proof of possession P′=μ′,σ′ where μ′=μ1′,μ2′,…,μd′ and σ′=σ1′,σ2′,…,σd′.
Analysis. C calculates actual proof P=μ,σ where μ=μ1,μ2,…,μd and σ=σ1,σ2,…,σd.
FurtherC computes the following values:(1)
σπ=∏u=1dσu and σπ′=∏u=1dσu′.(2)
μπ=∏u=1dQuμu and μπ′=∏u=1dQuμu′.(3)
For each,i∈C do the following:(a)
Getu such that Ii,u=1.(b)
Calculatewi=IDFiPu.
Both the proofsP and P′ should be valid as per the following equality:(35)eσπ,g=eμπ,Ppub.∏u=1de∏i∈CH2wiviIi,u,Pu,(36)eσπ′,g=eμπ′,Ppub.∏u=1de∏i∈CH2wiviIi,u,Pu.
Ifμπ=μπ′, then Adv3 stores the challenged message blocks correctly which contradicts our assumption. So, there are two cases.Case 1.
σπ=σπ′.
Equating (35) and (36),(37)e∏u=1dQuμu,Ppub=e∏u=1dQuμu′,Ppube∏u=1dQuμu,ga=e∏u=1dQuμu′,gae∏u=1dQuμu⋅a,g=e∏u=1dQuμu′⋅a,g,∏u=1dQuμu⋅a=∏u=1dQuμu′⋅a∏u=1dQuaΔμu=1,forΔμu=μu−μu′,ga∑u=1druΔμu⋅h2a∑u=1dβuΔμu=1h2a∑u=1dβuΔμu=h1∑u=1druΔμuh2a=h1−∑u=1druΔμu∑u=1dβuΔμuh1b=h1−∑u=1druΔμu∑u=1dβuΔμu.
Then,C can compute solution to discrete log of h2 as(38)b=−∑u=1druΔμu∑u=1dβuΔμu.
It can be observed that the solution to an instance of DL problem is found, unless the denominator∑u=1dβuΔμu is zero. However, at least one of Δμu is non-zero, and the values βu are randomly chosen by the challenger C from Zq∗. 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 DL problem in G1. For this to happen, the denominator in the exponent must be non-zero and its probability is 1−1/q. Hence, the minimum success probability ξ′k with which the challenger C can solve an instance of the given DL problem in G1 is ξ′k≥ξk⋅1−1/q. It can be noted that since q is exponentialk, the quantity 1−1/q is non-negligible. Thus, if ξk is non-negligible, then the success probability ξ′k is also non-negligible.Case 2.
σπ≠σπ′.
Dividing (26) by (20):(39)σπ′σπ=∏u=1dQuΔμuaσπ′σπ−1=∏u=1dQuΔμuaga∑u=1druΔμu⋅h2a∑u=1dβuΔμu=σπ′σπ−1h2a∑u=1dβuΔμu=σπ′σπ−1h1−∑u=1druΔμuh2a=σπ′σπ−1h1−∑u=1druΔμu1/∑u=1dβuΔμu.
C knows σπ,σπ′,Δμu,h1,ru,βu, and hence C can compute h2a, 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∑u=1dβ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 Zq∗. 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 G1 is ξ′k≥ξk⋅1−1/q. It can be noted that since q is exponentialk, the quantity 1−1/q is non-negligible. Thus, if ξk is non-negligible, then the success probability ξ′k is also non-negligible.
The running time ofC 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., H1 hash query t1, data-block query t2, public-key query t3, and tag-gen and H2 query t4 executed q1,q2,q3, and q4 times, respectively. Therefore, OC=OAdv3+Oq1⋅t1+q2⋅t2+q3⋅t3+q4⋅t4. Now since all the algorithms used in the simulation of challenger C are polynomial-time computable, OC=OAdv3+Oq1+q2+q3+q4. It can noted that q1,q2,q3, and q4 all are in polynomialk. Therefore, OC≈OAdv3. 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.


### 8.2. Soundness Proof for the Proposed CRPPA Scheme

The 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 Theorems1 and 2 against type-I and type-II attackers, respectively. Since the proposed CRPPA scheme employs zero-knowledge mechanisms to establish privacy-preserving 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. Theorem 2 bases on Theorem 1 to establish the soundness of the privacy-preserving mechanism used in the CRPPA scheme against type-III attacker. Theorem 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 Theorem 4.The 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 q1H3 hash queries and q2 data-block and tag-gen queries, where q1,q2 both are in polynomialk, and Prfrk denotes the forking probability as per forking lemma [67]. Then, the success probability, ξ′k, of challenger C in solving the above problem is lower bounded by(40)ξ′k≥ξk⋅1q1−1q,where q is the size of the co-domain Zq∗ of H3 hash function. In addition, the time complexity classes are OC≈OAdv3+Oq1+q2.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 challengechal without having at least one of the challenged blocks in its possession. Then, 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 parametersparams=G1,G2,q,e^,g,Ppub and instance of the challenge set chal=c,k1,k2,IDF, C segregates the challenge chal into d subsets, for each subset belongs to a unique user. C simulates game-3 in the following way.
Setup. C forwards params′=G1,G2,q,e^,g,g1,Ppub and a random tape to Adv3.
H3Hash Query. Adv3 queries for H3 for any value R∈G2. For each H3 query, C maintains a H3-List=R,γ. If R is already queried, C retrieves the tuple from the H3-List and returns γ to Adv3. If R is new, C randomly chooses a γ∈Zq∗ and sends γ 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. The 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 chalu=cu,k1,k2,IDF to Adv3.
Forge-Proof. Adv3 outputs privacy-preserving integrity proof P1u=μ1u′,Σu,ε1u,Ru. The value Ru must have been queried to the hash oracle where H3Ru=γ1u. Since the output of H3 hash oracle is uniformly random in Zq∗, the adversary Adv3 cannot obtain H3Ru without querying H3. However, H3Ru is essential in generating a valid proof P1u. Hence, the value of γ1u must have been queried.
C uses the forking technique to rewind the simulation to the instance where the value Ru is queried to the hash oracle. C replies γ2u as the hash value of Ru. Finally, Adv3 outputs privacy-preserving integrity proof P2u=μ2u′,Σu,ε2u,Ru.
Analysis. Calculate: μu=μ2u′−μ1u′/γ2u−γ1u, ρu=ε2u−ε1u/γ2u−γ1u, Σu=g1ρuσu, and σu=Σu/gρu.
Since both proofsP1u and P2u are valid proofs, they must satisfy auditor verification equation (20):(41)Ru⋅eΣuγ1u,g=eQuμ1u′,Ppub⋅eg1,gε1u,e∏i∈CuH2wiviIi,uγ1u,Pu,Ru⋅eΣuγ2u,g=eQuμ2u′,Ppub⋅eg1,gε1u,e∏i∈CuH2wiviIi,uγ2u,Pu.
Dividing (14) by (10), we get(42)eΣuγ2u−γ1u,g=eQuμ2u′−μ1u′,Ppub⋅eg1,gε2u−ε1u,e∏i∈CuH2wiviIi,uγ2u−γ1u,Pu.
Taking root of (γ2u−γ1u) on both sides:(43)eΣu,g=eQuμ2u′−μ1u′/γ2u−γ1u,Ppub⋅eg1,gε2u−ε1u/γ2u−γ1u,e∏i∈CuH2wiviIi,u,Pu.
Substituting the value ofΣu,μu,ρu, we get(44)eσu,g=eQuμu,Ppub.e∏i∈CH2wiviIi,u,Pu,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 challengechal 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. The 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 H3. We respond to a total of q1 number of RO queries received from the adversary Adv3. For each of these queries, we return a random value from the co-domain Zq∗. The output generated by the adversary algorithm Adv3 is the proof P1u which contains a component Ru. As stated earlier, Ru must have been queried to the hash oracle H3. Hence, the acceptance probability of the adversary algorithm Adv3 is Pracc=1. Thus, applying the forking lemma as stated in Section 3.2, the forking success probability Prfrk≥1/q1−1/Zq∗=1/q1−1/q. Hence, the minimum success probability with which the challenger C can generate a forged data audit proof against the basic CLS-RDIC scheme is ξ′k≥ξk⋅Prfrk=ξk⋅1/q1−1/q. It can be noted that Prfrk is non-negligible, since q1 is in polynomialk and q is in exponentialk. Thus, if ξk is non-negligible, then the success probability ξ′k is also non-negligible.
The running time ofC 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., H3 hash query t1 and data-block and tag-gen queries t2 executed q1 and q2 times, respectively. Therefore, OC=OAdv3+Oq1⋅t1+q2⋅t2. Now since all the algorithms used in the simulation of challenger C are polynomial-time computable, OC=OAdv1+Oq1+q2. It can be noted that q1 and q2 both are in polynomialk. Therefore, OC≈OAdv3. 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.
The proposed CRPPA protocol is secure against type-IV attacker, in the random oracle model. Suppose Adv4 makes at mostq1H1 hash queries, where q1 is in polynomialk. Then, the success probability that the simulator S can generate a valid data possession proof corresponding to a given challenge is(45)ξ′k≈1−1q,where q is the order of the group Zq∗. In addition, the time complexity classes are OC≈Oq1.Proof.
We prove the above theorem by showing that it is possible to design a simulatorS 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 H3 used in the masking technique of CRPPA. We show the success probability of such simulation to be non-negligible.
Setup. The simulator S receives a random tape and public parameters params.
H3Hash Query. In order to simulate H3 hash function as a random oracle, S maintains a H3-List=R,γ. If R is already queried, S retrieves the tuple from the H3-List and returns γ as the response. If R is new, S randomly chooses a γ∈Zq∗ and returns γ as the response.
Challenge. S receives the challenge set corresponding to a user IDu as chal=c,k1,k2,IDF,IDu.
Forge-Proof. After receiving the challenge chal=c,k1,k2,IDF,IDu, S computes the forged proof P using the following steps:(1)
C=i,vi, where i=πk1,x and vi=fk2,x for all 1≤x≤c where c is the number of challenged indices.(2)
Qu=H1IDu.(3)
Chooseγ,μ′,ε randomly from Zq∗.(4)
ChooseΣ randomly from G1.(5)
ComputeR=eQuμ′,Ppub⋅eg1,gε⋅e∏i∈CH2wiviγ,Pu/eΣ,gγ.(6)
IfR already exists in the H3-List, then abort the simulation.(7)
Else, setH3R←γ.
The simulatorS 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. The success probability of this simulation ξ′k = 1 − (failure probability of simulation) =(46)ξ′k=1−PF,where PF = the probability with which simulator S aborts. The simulation aborts only in step 6, when the value of R computed in step 5 already exists in H3-List.
Let polynomial numberql of H3 queries be received by the simulator S during the simulation. The probability that the value R computed in step 5 matches with any one of the previously queried H3 queries is proportional to ql/q, where q is the order of the group Zq∗. The value ql/q is an inverse exponential function of k, and thus ξ′k≈1−1/q is non-negligible.
The running time ofC is the upper bounded running time of the algorithm H3 hash query t1 executed q1 times, which is Oq1⋅t1. Now the algorithm used in the simulation S is polynomial-time computable, OC=Oq1. It can be noted that q1 is in polynomialk. Therefore, OC≈Opolynomialk. Hence, simulator S is polynomial-time algorithm.Theorem 6.
The aggregate verification done in the Verify-Proof algorithm of the proposed CRPPA protocol is sound. In other words, if the aggregate audit verification as per the Verify-Proof algorithm in Section7.2 results in success, then each of the t∈T instances of the data possession proofs is correct.Proof.
We prove the above given theorem through proof by contradiction. We know that∀t∈T, Pt=〈μ′t,Σtt,εt,Rt〉, where μ′t=μ1′t,μ2′t,…,μd′t, Σt=Σ1t,Σ2t,…,Σdt, εt=ε1t,ε2t,…,εdt, Rt=R1t,R2t,…,Rdt. We assume that there is at least one proof, say, the xth instance (for some x∈T) where the proof Px 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, thexth instance does not pass the verification test of Proof-Verify algorithm. Hence,(47)∏uRux⋅e∏uΣuxγux,g≠∏ueQuμu′x,Ppub⋅eg1εux,g⋅e∏i∈CxH2wiviIi,uγux,Pu.
But∀t∈T instances of the data possession proofs pass the verification test as per theVerify-Proof algorithm, which implies the following:(48)∏∀t∈T∏uRut⋅e∏∀t∈T∏uΣutγut,g=∏∀t∈T∏ue∏i∈CtH2wiviIi,uγut,Pu⋅e∏∀t∈T∏uQuμu′t,Ppub⋅eg1,g∑∀t∈T∑uεut.
The 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(49)∏∀t≠x∈T∏uRut⋅e∏∀t≠x∈T∏uΣutγut,g=∏∀t≠x∈T∏ue∏i∈CtH2wiviIi,uγut,Pu⋅e∏∀t≠x∈T∏uQuμu′t,Ppub⋅eg1,g∑∀t≠x∈T∑uεut.
Dividing (48) by (49), we get(50)∏uRux⋅e∏uΣuxγux,g=∏ueQuμu′x,Ppub⋅eg1εux,g⋅e∏i∈CxH2wiviIi,uγux,Pu.
Equation (50) shows that the xth 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 Section7.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 Theorem 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. The 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.


#### 8.2.2. 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 audit-verifier, can always verify thetimeliness of the auditing task performed by the auditor, as explained in the Verify-Proof algorithm of the CRPPA protocol.


## 8.1. 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 Section8.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 Theorems 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 Theorem 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.The 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 inG1 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 G1. Suppose Adv1 makes at most q1H1 hash queries, q2 partial-private-key queries, q3 secret-value queries, q4 public-key queries, q5 public-key-replace queries, q6H2 hash queries, and q7 tag-gen queries, where q1,q2,q3,q4,q5,q6,q7 all are in polynomialk; then, the success probability, ξ′k, of challenger C in solving the above problem is lower bounded by(30)ξ′k≥ξke⋅1+q2+q7,where e≈2.71828 is the base of the natural logarithm. In addition, the time complexity classes are OC≈OAdv1+Oq1+q2+q3+q4+q5+q6+q7.Proof.
Let Adv1 be the adversary as in game-1 who is capable of forging a tag. Then, we construct a simulatorC using Adv1 as subroutine to solve the CDH problem in G1. C simulates game-1 in the following way.
Setup. Given a CDH problem instance q,G1,g,h1,h2, h1=gα, for some α∈Zq∗. C chooses another cyclic multiplicative group G2, G1=G2=q, and an admissible bilinear map e^=G1×G1⟶G2. C sets the public parameters params=G1,G2,q,e^,g,Ppub=h1,H1,H2 and sends params to Adv1. Note that the master secret key(α) is unknown to the challenger C.
H1Hash Query. Adv1 adaptively queries for H1 for any identity IDu. For every H1 query, C maintains a list H1-List=IDu,Qu,ru,Su,Pu,bu. If the IDu is already queried before, C simply retrieves the tuple from the H1-List and returns Qu to Adv1. If IDu is new, C randomly picks ru∈Zq∗ and tosses a coin bu∈0,1, where the probability of bu=0 is φ and that of bu=1 is 1−φ. If bu=0, then C sets Qu=gru, chooses a random value βu∈Zq∗, and sets Su=βu and Pu=gβu. Else if bu=1, then C sets Qu=h2⋅gru, chooses a random value βu∈Zq∗, and sets Su=βu and Pu=gβu. Finally, C inserts the values IDu,Qu,ru,Su,Pu,bu into H1-List. Return Qu to Adv1.
Partial-Private-Key Query. Adv1 adaptively queries for partial-private-key for any identity IDu. C scans for IDu in H1-List. If IDu does not exist in H1-List, C queries itself for H1IDu. If bu=0, then retrieve ru from H1-List set Du=h1ru and return Du to Adv1. Else if bu=1, then abort.
Secret-Value Query. Adv1 adaptively queries for set-secret-value for any identity IDu. C scans for IDu in H1-List. If IDu does not exist in H1-List, C queries itself for H1IDu. If Su=⊥, C chooses a random value βu∈Zq∗ and sets Su=βu and Pu=gβu. C updates the values Su,Pu into H1-List and returns Su to Adv1.
Public-Key Query. Adv1 adaptively queries for public-key for any identity IDu. C scans for IDu in H1-List. If IDu does not exist in H1-List, C queries itself for H1IDu. C retrieves Pu and returns it to Adv1.
Public-Key-Replace Query. Adv1 adaptively queries for a public-key replacement for any identity IDu with IDu,Pu′. C scans for IDu in H1-List. If IDu does not exist in H1-List, C queries itself for H1IDu. C sets Su=⊥ and Pu=Pu′ and updates H1-List.
H2Hash Query. Adv1 adaptively queries for wk,Pu. For every H2 query, C maintains a list H2-List=wk,Hk2,rk,Pu. C scans H2-List for wk,Pu. If wk,Pu does not exist in H2-List, C randomly chooses rk∈Zq∗, sets Hk2=grk, and updates H2-List. C returns Hk2 to Adv1.
Tag-Gen Query. Adv1 adaptively queries with the values m,wk,IDu. If IDu does not exist in H1-List, C queries itself for H1IDu. C retrieves Pu from H1-List. If bu=0, then, C queries for Du. C scans for wk,Pu in H2-List, and if it exists, then retrieve Hk2; else, C self-queries for Hk2 with the values wk,Pu. Now C retrieves Su from H1-List for IDu. It computes tag σ=Dum⋅Hk2Su. Else if bu=1 and wk,Puexists in H2-List, then abort. Else select randomly rk∈Zq∗, compute Hk2=grk⋅h1−m, set Pu=h2, compute σ=h1rum⋅h2rk, and finally insert the tuple wk,Hk2,⊥,Pu to H2-List. C returns σ to Adv1
Forge-Tag. Adv1 outputs a tuple σ′,m′,wk′,IDu′,Pu′, where σ′ is the forged tag on the message m′ with authenticating information wk′ for identity IDu′ with public key Pu′.
Analysis. If Adv1 successfully forges the tag, then the tuple should be valid. If bu=0, then C aborts. Else if bu=1, C uses the following verification equation: eσ′,g=eH1IDu′m′,Ppub⋅eH2wk′,Pu′,Pu′. C retrieves the tuple from H1-List for the forged IDu′, and C retrieves the value of Qu=h2⋅gru from H1-List and H2wk′,Pu′=grk′ from H2-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,h1=gα,h2), C calculates h2α as follows.
As per the verification equation:(31)eσ′,g=eh2⋅grum,Ppub⋅egrk′,Pu′,eσ′,g=eh2α⋅m′⋅gαru⋅m′,g⋅ePu′rk′,g,h2α=σ′Pu′rk′⋅h1ru⋅m′1/m′.
We now calculate the minimum success probabilityξ′k with which the challenger C can solve an instance of the given CDH problem in G1. For this to happen, the challenger C must not abort during the above simulation. There 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. The partial-private-key query phase and the tag-gen query phase do not abort when bu=0, whereas the analysis phase does not abort when bu=1. Hence, the probability that the challenger C does not abort the above simulation is 1−φ⋅φq2+q7. The quantity 1−φ⋅φq2+q7 is maximized when φ=φmax=q2+q7/1+q2+q7. 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+q2+q7. Hence, the minimum success probability with which the challenger C can solve an instance of the given CDH problem is ξ′k≥ξk/e⋅1+q2+q7. It can be noted that since q2 and q7 are polynomialk, the quantity 1/1+q2+q7 is non-negligible. Thus, if ξk is non-negligible, then the success probability ξ′k is also non-negligible.
The running time ofC 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., H1 hash query t1, partial-private-key query t2, secret-value query t3, public-key query t4, public-key-replace query t5, H2 hash query t6, and tag-gen query t7 executed q1,q2,q3,q4,q5,q6, and q7 times, respectively. Therefore, OC=OAdv1+Oq1⋅t1+q2⋅t2+q3⋅t3+q4⋅t4+q5⋅t5+q6⋅t6+q7⋅t7. Now since all the algorithms used in the simulation of challenger C are polynomial-time computable, OC=OAdv1+Oq1+q2+q3+q4+q5+q6+q7. It can be noted that q1,q2,q3,q4,q5,q6, and q7 all are in polynomialk. Therefore, OC≈OAdv1. It can be observed that if Adv1 is a polynomial-time algorithm, then the simulated CDH problem solver C is also a polynomial-time algorithm.
The 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 inG1 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 G1. Suppose Adv2 makes at most q1H1 hash queries, q2 secret-value queries, q3 public-key queries, and q4H2 hash queries, where q1,q2,q3, and q4 all are in polynomialk; then, the success probability, ξ′k, of challenger C in solving the above problem is lower bounded by(32)ξ′k≥ξke⋅1+q2,where e≈2.71828 is the base of the natural logarithm. In addition, the time complexity classes are OC≈OAdv2+Oq1+q2+q3+q4.Proof.
Let Adv2 be the adversary as in game-2 who is capable of forging a tag. Then, we construct an adversaryC using Adv2 as subroutine to solve the CDH problem in G1. C simulates game-2 in the following way.
Setup. Given an instance of CDH problem (g,G1,h1=gα,h2). C randomly picks s∈Zq∗, chooses another cyclic multiplicative group G2, G1=G2=q, and an admissible bilinear map e^:G1×G1⟶G2, and sets the public parameters params=G1,G2,q,e^,g,Ppub=gs,H1,H2. C sends params and s to Adv2, and s is the master secret key.
H1Hash Query. Adv2 adaptively queries for H1 for any identity IDu. For every H1 query, C maintains a list H1-List=IDu,Qu,ru,Su,Pu. If the IDu is already queried before, C simply retrieves the tuple from the H1-List and returns Qu to Adv2. If IDu is new, C randomly picks ru,βu∈Zq∗, sets Qu=gru, and tosses a coin bu∈0,1, where the probability of bu=0 is φ and that of bu=1 is 1−φ . If bu=0, then C sets Pu=gβu and Su=βu. Else if bu=1, then C sets Pu=h1βu and Su=⊥. Finally, C inserts the values IDu,Qu,ru,Su,Pu into H1-List. C returns Qu to Adv2.
Secret-Value Query. Adv2 adaptively queries for set-secret-value for any identity IDu. C scans for IDu in H1-List. If IDu does not exist, C queries itself for H1IDu. If bu=1, abort; else, C retrieves Su and returns it to Adv2.
Public-Key Query. Adv2 adaptively queries for public-key for any identity IDu. C scans for IDu in H1-List. If IDu does not exist, C queries itself for H1IDu. C retrieves Pu and returns it to Adv2.
H2Hash Query. Adv2 adaptively queries for wk,Pu. For every H2 query, C maintains a list H2-List=wk,Hk2,rk,Pu. C scans H2-List for wk,Pu. If wk,Pu does not exist, C randomly chooses rk∈Zq∗, sets Hk2=h2rk, and updates H2-List. C retrieves Hk2 and returns it to Adv2.
Forge-Tag. Adv2 outputs a tuple σ′,m′,wk′,IDu′,Pu′, where σ′ is the forged tag on the message m′ with authenticating information wk′ for identity IDu′ with public key Pu′.
Analysis. If Adv2 successfully forges the tag, then the tuple should be valid. If bu=0, then C aborts. Else if bu=1, C uses the following verification equation: eσm′,g=eH1IDu′m′,Ppub⋅eH2wk′,Pu′,Pu′. C retrieves the tuple from H1-List for the forged IDu′, and C retrieves the value of Qu=gru from H1-List and H2wk′,Pu′=h2rk′ from H2-List.
As per the verification equation:(33)eσ′,g=egru′⋅m′,Ppub⋅eh2rk′,gα⋅βu,eσ′,g=egru′⋅m′⋅s,g⋅eh2rk′⋅α⋅βu,g,h2α=σ′gru′⋅m′⋅s1/rk′⋅βu.
We now calculate the minimum success probabilityξ′k with which the challenger C can solve an instance of the given CDH problem in G1. For this to happen, the challenger C must not abort during the above simulation. There are two phases in the simulation where the challenger C can abort, i.e., in secret-value query phase and analysis phase. The secret-value query phase does not abort when bu=0, whereas the analysis phase does not abort when bu=1. Hence, the probability that the challenger C does not abort the above simulation is 1−φ⋅φq2. The quantity 1−φ⋅φq2 is maximized when φ=φmax=q2/1+q2. 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+q2. Hence, the minimum success probability with which the challenger C can solve an instance of the given CDH problem is ξ′k≥ξk/e⋅1+q2. It can be noted that since q2 is polynomialk, the quantity 1/1+q2 is non-negligible. Thus, if ξk is non-negligible, then the success probability ξ′k is also non-negligible.
The running time ofC 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., H1 hash query t1, secret-value query t2, public-key query t3, and H2 hash query t4 executed q1,q2,q3, and q4, times respectively. Therefore, OC=OAdv2+Oq1⋅t1+q2⋅t2+q3⋅t3+q4⋅t4. Now since all the algorithms used in the simulation of challenger C are polynomial-time computable, OC=OAdv2+Oq1+q2+q3+q4. It can noted that q1,q2,q3, and q4 all are in polynomialk. Therefore, OC≈OAdv2. 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.
The 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 inG1 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 G1. Suppose Adv3 makes at most q1H1 hash queries, q2 data-block queries, q3 public-key queries, and q4 tag-gen and H2 queries, where q1,q2,q3,q4 all are in polynomialk; then, the success probability, ξ′k, of challenger C in solving the above problem is lower bounded by(34)ξ′k≥ξk⋅1−1q,where q is the order of the group G1. In addition, the time complexity classes are OC≈OAdv3+Oq1+q2+q3+q4.Proof.
Let Adv3 be the adversary as in game-3 who is capable of generating a valid data possession proof for the challenged blocks. Then, we construct a PPT simulatorC using Adv3 as subroutine to solve either the DH or the CDH problem in G1. C simulates game-3 in the following way.
Setup. Given an instance of CDH problem g,G1,h1=ga,h2=gb and an instance of the DL problem g,G1,h2=gb. C chooses another cyclic multiplicative group G2, where G1=G2=q, and an admissible bilinear map e^:G1×G1⟶G2, sets the public parameters params=G1,G2,q,e^,g,Ppub=h1, and sends params to Adv3, and a and b are unknown to C.
H1Hash Query. Adv3 adaptively queries for H1 for any identity IDu. For every H1 query, C maintains a list H1-List=IDu,Qu,ru,βu,Pu. If IDu is already queried before, C simply retrieves the tuple from the H1-List and returns Qu to Adv3. If IDu is new, C randomly picks ru,βu∈Zq∗ and sets Qu=gruh2βu and Pu=h2βu. Finally, it inserts the values IDu,Qu,ru,βu,Pu into H1-List. C returns Qu to Adv3.
Data-Block Query. The file F=m1,…,mn with file identifier IDF 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. Then, C retrieves corresponding data block from the date file IDF and forwards to Adv3.
Public-Key Query. Adv3 adaptively queries for the public key of any identity IDu. C scans for IDu in H1-List, and if IDu does not exist, C queries itself for H1IDu. C retrieves Pu and returns it to Adv3.
Tag-Gen Query andH2Query. C maintains a list H2′-List=i,bi,H2IDFiPu,σi and computes tag for each index in IDF corresponding to user u shown in indicator matrix I as follows.
C randomly picks bi∈Zq∗, for i∈1,…,n. For each index i, C computes H2IDFiPu=gbih1−mi and σi=h1rumi⋅h2biβu, where βu and ru are retrieved from H1-List corresponding to Pu.
The validity of the tag simulation can be verified as follows.
As per the tag-gen algorithm,σi=DumiH2IDFiPubβu.
As per simulation,σi=Quamigbih1−mibβu.
By replacing value ofQu, σi=gru⋅h2βuami⋅gbbiβu⋅h1−bmiβu.
By replacing values ofh1,h2, σi=garumi⋅gabmiβu⋅gbbiβu⋅g−abmiβu.
σi=garumi⋅gbbiβu=h1rumi⋅h2biβu.
C adds the following tuple to its list H2′-List=i,bi,H2IDFiPu,σi. C sends σ1,...,σn, corresponding file F=m1,…,mn and indicator matrix Ii,u to Adv3.
Challenge. C chooses a number c (1≤c≤n) as the size of the challenge vector and two random values k1,k2∈0,1l 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,C=i,vi,IDF to the Adv3, where i=πk1,x, vi=fk2,x for 1≤x≤c.
Forge-Proof. Eventually Adv3 outputs proof of possession P′=μ′,σ′ where μ′=μ1′,μ2′,…,μd′ and σ′=σ1′,σ2′,…,σd′.
Analysis. C calculates actual proof P=μ,σ where μ=μ1,μ2,…,μd and σ=σ1,σ2,…,σd.
FurtherC computes the following values:(1)
σπ=∏u=1dσu and σπ′=∏u=1dσu′.(2)
μπ=∏u=1dQuμu and μπ′=∏u=1dQuμu′.(3)
For each,i∈C do the following:(a)
Getu such that Ii,u=1.(b)
Calculatewi=IDFiPu.
Both the proofsP and P′ should be valid as per the following equality:(35)eσπ,g=eμπ,Ppub.∏u=1de∏i∈CH2wiviIi,u,Pu,(36)eσπ′,g=eμπ′,Ppub.∏u=1de∏i∈CH2wiviIi,u,Pu.
Ifμπ=μπ′, then Adv3 stores the challenged message blocks correctly which contradicts our assumption. So, there are two cases.Case 1.
σπ=σπ′.
Equating (35) and (36),(37)e∏u=1dQuμu,Ppub=e∏u=1dQuμu′,Ppube∏u=1dQuμu,ga=e∏u=1dQuμu′,gae∏u=1dQuμu⋅a,g=e∏u=1dQuμu′⋅a,g,∏u=1dQuμu⋅a=∏u=1dQuμu′⋅a∏u=1dQuaΔμu=1,forΔμu=μu−μu′,ga∑u=1druΔμu⋅h2a∑u=1dβuΔμu=1h2a∑u=1dβuΔμu=h1∑u=1druΔμuh2a=h1−∑u=1druΔμu∑u=1dβuΔμuh1b=h1−∑u=1druΔμu∑u=1dβuΔμu.
Then,C can compute solution to discrete log of h2 as(38)b=−∑u=1druΔμu∑u=1dβuΔμu.
It can be observed that the solution to an instance of DL problem is found, unless the denominator∑u=1dβuΔμu is zero. However, at least one of Δμu is non-zero, and the values βu are randomly chosen by the challenger C from Zq∗. 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 DL problem in G1. For this to happen, the denominator in the exponent must be non-zero and its probability is 1−1/q. Hence, the minimum success probability ξ′k with which the challenger C can solve an instance of the given DL problem in G1 is ξ′k≥ξk⋅1−1/q. It can be noted that since q is exponentialk, the quantity 1−1/q is non-negligible. Thus, if ξk is non-negligible, then the success probability ξ′k is also non-negligible.Case 2.
σπ≠σπ′.
Dividing (26) by (20):(39)σπ′σπ=∏u=1dQuΔμuaσπ′σπ−1=∏u=1dQuΔμuaga∑u=1druΔμu⋅h2a∑u=1dβuΔμu=σπ′σπ−1h2a∑u=1dβuΔμu=σπ′σπ−1h1−∑u=1druΔμuh2a=σπ′σπ−1h1−∑u=1druΔμu1/∑u=1dβuΔμu.
C knows σπ,σπ′,Δμu,h1,ru,βu, and hence C can compute h2a, 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∑u=1dβ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 Zq∗. 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 G1 is ξ′k≥ξk⋅1−1/q. It can be noted that since q is exponentialk, the quantity 1−1/q is non-negligible. Thus, if ξk is non-negligible, then the success probability ξ′k is also non-negligible.
The running time ofC 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., H1 hash query t1, data-block query t2, public-key query t3, and tag-gen and H2 query t4 executed q1,q2,q3, and q4 times, respectively. Therefore, OC=OAdv3+Oq1⋅t1+q2⋅t2+q3⋅t3+q4⋅t4. Now since all the algorithms used in the simulation of challenger C are polynomial-time computable, OC=OAdv3+Oq1+q2+q3+q4. It can noted that q1,q2,q3, and q4 all are in polynomialk. Therefore, OC≈OAdv3. 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.


## 8.2. Soundness Proof for the Proposed CRPPA Scheme

The 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 Theorems1 and 2 against type-I and type-II attackers, respectively. Since the proposed CRPPA scheme employs zero-knowledge mechanisms to establish privacy-preserving 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. Theorem 2 bases on Theorem 1 to establish the soundness of the privacy-preserving mechanism used in the CRPPA scheme against type-III attacker. Theorem 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 Theorem 4.The 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 q1H3 hash queries and q2 data-block and tag-gen queries, where q1,q2 both are in polynomialk, and Prfrk denotes the forking probability as per forking lemma [67]. Then, the success probability, ξ′k, of challenger C in solving the above problem is lower bounded by(40)ξ′k≥ξk⋅1q1−1q,where q is the size of the co-domain Zq∗ of H3 hash function. In addition, the time complexity classes are OC≈OAdv3+Oq1+q2.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 challengechal without having at least one of the challenged blocks in its possession. Then, 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 parametersparams=G1,G2,q,e^,g,Ppub and instance of the challenge set chal=c,k1,k2,IDF, C segregates the challenge chal into d subsets, for each subset belongs to a unique user. C simulates game-3 in the following way.
Setup. C forwards params′=G1,G2,q,e^,g,g1,Ppub and a random tape to Adv3.
H3Hash Query. Adv3 queries for H3 for any value R∈G2. For each H3 query, C maintains a H3-List=R,γ. If R is already queried, C retrieves the tuple from the H3-List and returns γ to Adv3. If R is new, C randomly chooses a γ∈Zq∗ and sends γ 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. The 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 chalu=cu,k1,k2,IDF to Adv3.
Forge-Proof. Adv3 outputs privacy-preserving integrity proof P1u=μ1u′,Σu,ε1u,Ru. The value Ru must have been queried to the hash oracle where H3Ru=γ1u. Since the output of H3 hash oracle is uniformly random in Zq∗, the adversary Adv3 cannot obtain H3Ru without querying H3. However, H3Ru is essential in generating a valid proof P1u. Hence, the value of γ1u must have been queried.
C uses the forking technique to rewind the simulation to the instance where the value Ru is queried to the hash oracle. C replies γ2u as the hash value of Ru. Finally, Adv3 outputs privacy-preserving integrity proof P2u=μ2u′,Σu,ε2u,Ru.
Analysis. Calculate: μu=μ2u′−μ1u′/γ2u−γ1u, ρu=ε2u−ε1u/γ2u−γ1u, Σu=g1ρuσu, and σu=Σu/gρu.
Since both proofsP1u and P2u are valid proofs, they must satisfy auditor verification equation (20):(41)Ru⋅eΣuγ1u,g=eQuμ1u′,Ppub⋅eg1,gε1u,e∏i∈CuH2wiviIi,uγ1u,Pu,Ru⋅eΣuγ2u,g=eQuμ2u′,Ppub⋅eg1,gε1u,e∏i∈CuH2wiviIi,uγ2u,Pu.
Dividing (14) by (10), we get(42)eΣuγ2u−γ1u,g=eQuμ2u′−μ1u′,Ppub⋅eg1,gε2u−ε1u,e∏i∈CuH2wiviIi,uγ2u−γ1u,Pu.
Taking root of (γ2u−γ1u) on both sides:(43)eΣu,g=eQuμ2u′−μ1u′/γ2u−γ1u,Ppub⋅eg1,gε2u−ε1u/γ2u−γ1u,e∏i∈CuH2wiviIi,u,Pu.
Substituting the value ofΣu,μu,ρu, we get(44)eσu,g=eQuμu,Ppub.e∏i∈CH2wiviIi,u,Pu,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 challengechal 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. The 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 H3. We respond to a total of q1 number of RO queries received from the adversary Adv3. For each of these queries, we return a random value from the co-domain Zq∗. The output generated by the adversary algorithm Adv3 is the proof P1u which contains a component Ru. As stated earlier, Ru must have been queried to the hash oracle H3. Hence, the acceptance probability of the adversary algorithm Adv3 is Pracc=1. Thus, applying the forking lemma as stated in Section 3.2, the forking success probability Prfrk≥1/q1−1/Zq∗=1/q1−1/q. Hence, the minimum success probability with which the challenger C can generate a forged data audit proof against the basic CLS-RDIC scheme is ξ′k≥ξk⋅Prfrk=ξk⋅1/q1−1/q. It can be noted that Prfrk is non-negligible, since q1 is in polynomialk and q is in exponentialk. Thus, if ξk is non-negligible, then the success probability ξ′k is also non-negligible.
The running time ofC 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., H3 hash query t1 and data-block and tag-gen queries t2 executed q1 and q2 times, respectively. Therefore, OC=OAdv3+Oq1⋅t1+q2⋅t2. Now since all the algorithms used in the simulation of challenger C are polynomial-time computable, OC=OAdv1+Oq1+q2. It can be noted that q1 and q2 both are in polynomialk. Therefore, OC≈OAdv3. 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.
The proposed CRPPA protocol is secure against type-IV attacker, in the random oracle model. Suppose Adv4 makes at mostq1H1 hash queries, where q1 is in polynomialk. Then, the success probability that the simulator S can generate a valid data possession proof corresponding to a given challenge is(45)ξ′k≈1−1q,where q is the order of the group Zq∗. In addition, the time complexity classes are OC≈Oq1.Proof.
We prove the above theorem by showing that it is possible to design a simulatorS 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 H3 used in the masking technique of CRPPA. We show the success probability of such simulation to be non-negligible.
Setup. The simulator S receives a random tape and public parameters params.
H3Hash Query. In order to simulate H3 hash function as a random oracle, S maintains a H3-List=R,γ. If R is already queried, S retrieves the tuple from the H3-List and returns γ as the response. If R is new, S randomly chooses a γ∈Zq∗ and returns γ as the response.
Challenge. S receives the challenge set corresponding to a user IDu as chal=c,k1,k2,IDF,IDu.
Forge-Proof. After receiving the challenge chal=c,k1,k2,IDF,IDu, S computes the forged proof P using the following steps:(1)
C=i,vi, where i=πk1,x and vi=fk2,x for all 1≤x≤c where c is the number of challenged indices.(2)
Qu=H1IDu.(3)
Chooseγ,μ′,ε randomly from Zq∗.(4)
ChooseΣ randomly from G1.(5)
ComputeR=eQuμ′,Ppub⋅eg1,gε⋅e∏i∈CH2wiviγ,Pu/eΣ,gγ.(6)
IfR already exists in the H3-List, then abort the simulation.(7)
Else, setH3R←γ.
The simulatorS 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. The success probability of this simulation ξ′k = 1 − (failure probability of simulation) =(46)ξ′k=1−PF,where PF = the probability with which simulator S aborts. The simulation aborts only in step 6, when the value of R computed in step 5 already exists in H3-List.
Let polynomial numberql of H3 queries be received by the simulator S during the simulation. The probability that the value R computed in step 5 matches with any one of the previously queried H3 queries is proportional to ql/q, where q is the order of the group Zq∗. The value ql/q is an inverse exponential function of k, and thus ξ′k≈1−1/q is non-negligible.
The running time ofC is the upper bounded running time of the algorithm H3 hash query t1 executed q1 times, which is Oq1⋅t1. Now the algorithm used in the simulation S is polynomial-time computable, OC=Oq1. It can be noted that q1 is in polynomialk. Therefore, OC≈Opolynomialk. Hence, simulator S is polynomial-time algorithm.Theorem 6.
The aggregate verification done in the Verify-Proof algorithm of the proposed CRPPA protocol is sound. In other words, if the aggregate audit verification as per the Verify-Proof algorithm in Section7.2 results in success, then each of the t∈T instances of the data possession proofs is correct.Proof.
We prove the above given theorem through proof by contradiction. We know that∀t∈T, Pt=〈μ′t,Σtt,εt,Rt〉, where μ′t=μ1′t,μ2′t,…,μd′t, Σt=Σ1t,Σ2t,…,Σdt, εt=ε1t,ε2t,…,εdt, Rt=R1t,R2t,…,Rdt. We assume that there is at least one proof, say, the xth instance (for some x∈T) where the proof Px 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, thexth instance does not pass the verification test of Proof-Verify algorithm. Hence,(47)∏uRux⋅e∏uΣuxγux,g≠∏ueQuμu′x,Ppub⋅eg1εux,g⋅e∏i∈CxH2wiviIi,uγux,Pu.
But∀t∈T instances of the data possession proofs pass the verification test as per theVerify-Proof algorithm, which implies the following:(48)∏∀t∈T∏uRut⋅e∏∀t∈T∏uΣutγut,g=∏∀t∈T∏ue∏i∈CtH2wiviIi,uγut,Pu⋅e∏∀t∈T∏uQuμu′t,Ppub⋅eg1,g∑∀t∈T∑uεut.
The 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(49)∏∀t≠x∈T∏uRut⋅e∏∀t≠x∈T∏uΣutγut,g=∏∀t≠x∈T∏ue∏i∈CtH2wiviIi,uγut,Pu⋅e∏∀t≠x∈T∏uQuμu′t,Ppub⋅eg1,g∑∀t≠x∈T∑uεut.
Dividing (48) by (49), we get(50)∏uRux⋅e∏uΣuxγux,g=∏ueQuμu′x,Ppub⋅eg1εux,g⋅e∏i∈CxH2wiviIi,uγux,Pu.
Equation (50) shows that the xth 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 Section7.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 Theorem 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. The 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.


### 8.2.2. 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 audit-verifier, can always verify thetimeliness of the auditing task performed by the auditor, as explained in the Verify-Proof algorithm of the CRPPA protocol.


## 8.2.1. Security against Type-V Attack

Type-V attack can be launched in two different ways as discussed in Section7.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 Theorem 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. The 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.


## 8.2.2. 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 audit-verifier, can always verify thetimeliness of the auditing task performed by the auditor, as explained in the Verify-Proof algorithm of the CRPPA protocol.


## 9. 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 well-known schemes in the remote data integrity checking field to understand the performance of the CRPPA scheme in the broad area of RDIC.


### 9.1. A Qualitative Comparison of the Proposed CRPPA Scheme

Table3 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).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 schemeJaya 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]Li et al. [62]Cryptography usedCLPKCCLPKCCLPKCCLPKCCLPKCPKICLPKCID-PKCCLPKCGroup shared dataYesYesYesYesYesNoNoNoYesType-I secureYesNoYesNoNo—YesNoNoType-II secureYesNoYesNoNo—YesNoNoType-III secureYesNo—NoNoYesYesNoNoType-IV secureYesNoYesYesNoNoNoYesNoType-V secureYesNoNoNoNoYesYesNoNoType-VI secureYesNoNoNoNoNoYesNoNoWe discuss the specific security limitations of the schemes in [12, 21, 23–25, 39, 48, 62] against our proposed CRPPA scheme. The 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). The 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. Thus, 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, Table4 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. The 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. The 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. The security against type-IV attack in scheme [23] is based on CDH assumption and that in schemes [12, 39] is based on the one-way 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. The 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.Table 4
Comparison of the proposed CRPPA scheme with the schemes in [12, 21, 23–25, 39, 48, 62] on the difficulty assumption employed against six types of attacks.
Proposed CRPPA schemeJaya 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]Li et al. [62]Type ICDHCDHCDHCDHCDH—CDH—CDHType IICDHCDHCDHCDHCDH—CDH—CDHType IIICDH & DLDL—DL—CDH & DLCDH—DLType IVDLCDHDLOne-way property of hash function———One-way property of hash function—Type VConsensus mechanism of blockchain————Consensus mechanism of blockchainProof-of-work mechanism in blockchain——Type VIImmutability property of blockchain—————Immutability property of blockchain——Note. “—” indicates not applicable.


### 9.2. Computation Cost

To understand the performance of the proposed CRPPA scheme in the broad area of RDIC, we consider three well-known RDIC schemes. The first is Li et al.’s CLS-based group shared data auditing scheme [62], and we refer to this scheme as certificateless-RDIC scheme. The 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. The 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 G1, exponentiation in G1, multiplication in G1 and G2, and bilinear pairing operation. Let us denote their costs as TH,TexpG1,TmulG1,TmulG2, and Tp, respectively.Table 5
Cryptographic operations cost at the auditor.
SchemeProof verification costCRPPAcTH+c+2TexpG1+c−1TmulG1+TmulG2+3TpCertificateless-RDIC [62]cTH+c+1TexpG1+c−1TmulG1+TmulG2+3TpID-RDIC [12]cTH+cTexpG1+c−1TmulG1+1TpBlockchain-RDIC [25]cTH+c+4TexpG1+c+1TmulG1+2TmulG2+4TpTable 6
Cryptographic operations cost at the CSP.
SchemeProof generation costCRPPAcTexpG1+cTmulG1Certificateless-RDIC [62]cTexpG1+c−1TmulG1ID-RDIC [12]c+1TexpG1+c−1TmulG1+TmulG2+2TpBlockchain-RDIC [25]cTexpG1+c−1TmulG1Table 7
Cryptographic operations cost at the user.
SchemeTag generation costCRPPAbTH+2bTexpG1+bTmulG1Certificateless-RDIC [62]bTH+2bTexpG1+bTmulG1ID-RDIC [12]bTH+2bTexpG1+bTmulG1Blockchain-RDIC [25]b+3TH+2b+5TexpG1+2b+1TmulG1The valuec 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. The 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.


### 9.3. Experimentation Results

In Section9.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 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]. The cost for the tag-generation mechanism for the user can be split into two types. The 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. The 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 Quad-core Cortex-A7 mobile processor@1.6 GHz and 2 GB RAM for simulating the edge user device and edge data auditor device. The benchmark execution time in milliseconds for each cryptographic operation TH,TexpG1,TmulG1,TmulG2, and Tp 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.Table 8
Execution times of various cryptographic operations.
OperationLinux PC device (millisecond)Android mobile device (millisecond)Bilinear pairingTp3.2518.42Hash-to-element inG1TH0.66.78Multiplication inG1TmulG10.050.1Exponentiation inG1TexpG10.252.87Multiplication inG2TmulG21.458.76Figure1 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. This 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. The 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 tag-generation 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. The 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. This 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.Figure 1
Performance comparison of various computation costs of our proposed CRPPA scheme with other related schemes.Overall, from Figure1, 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]. This is because the number of major cryptographic operations, such as TH,TexpG1,TmulG1,TmulG2, and Tp, required for implementing each of the offline and online tag-generation algorithms executed by an edge user device, the proof-generation algorithm executed by the CSP, and the proof-verification algorithm executed by the data auditor in the proposed scheme and in the compared schemes is almost the same, as listed in Tables 5–7. Hence, the results confirm that the proposed protocol achieves its additional security objectives with marginal increase in the cost. Besides, the aggregate verification cost of verifying n number of audit reports by an audit-verifier in our proposed CRPPA scheme, as shown in the Verify-Proof algorithm of Section 7.2, has only 1/3rd of the computation cost required by an auditor to verify the same n number of data possession proofs.


## 9.1. A Qualitative Comparison of the Proposed CRPPA Scheme

Table3 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).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 schemeJaya 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]Li et al. [62]Cryptography usedCLPKCCLPKCCLPKCCLPKCCLPKCPKICLPKCID-PKCCLPKCGroup shared dataYesYesYesYesYesNoNoNoYesType-I secureYesNoYesNoNo—YesNoNoType-II secureYesNoYesNoNo—YesNoNoType-III secureYesNo—NoNoYesYesNoNoType-IV secureYesNoYesYesNoNoNoYesNoType-V secureYesNoNoNoNoYesYesNoNoType-VI secureYesNoNoNoNoNoYesNoNoWe discuss the specific security limitations of the schemes in [12, 21, 23–25, 39, 48, 62] against our proposed CRPPA scheme. The 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). The 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. Thus, 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, Table4 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. The 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. The 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. The security against type-IV attack in scheme [23] is based on CDH assumption and that in schemes [12, 39] is based on the one-way 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. The 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.Table 4
Comparison of the proposed CRPPA scheme with the schemes in [12, 21, 23–25, 39, 48, 62] on the difficulty assumption employed against six types of attacks.
Proposed CRPPA schemeJaya 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]Li et al. [62]Type ICDHCDHCDHCDHCDH—CDH—CDHType IICDHCDHCDHCDHCDH—CDH—CDHType IIICDH & DLDL—DL—CDH & DLCDH—DLType IVDLCDHDLOne-way property of hash function———One-way property of hash function—Type VConsensus mechanism of blockchain————Consensus mechanism of blockchainProof-of-work mechanism in blockchain——Type VIImmutability property of blockchain—————Immutability property of blockchain——Note. “—” indicates not applicable.


## 9.2. Computation Cost

To understand the performance of the proposed CRPPA scheme in the broad area of RDIC, we consider three well-known RDIC schemes. The first is Li et al.’s CLS-based group shared data auditing scheme [62], and we refer to this scheme as certificateless-RDIC scheme. The 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. The 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 G1, exponentiation in G1, multiplication in G1 and G2, and bilinear pairing operation. Let us denote their costs as TH,TexpG1,TmulG1,TmulG2, and Tp, respectively.Table 5
Cryptographic operations cost at the auditor.
SchemeProof verification costCRPPAcTH+c+2TexpG1+c−1TmulG1+TmulG2+3TpCertificateless-RDIC [62]cTH+c+1TexpG1+c−1TmulG1+TmulG2+3TpID-RDIC [12]cTH+cTexpG1+c−1TmulG1+1TpBlockchain-RDIC [25]cTH+c+4TexpG1+c+1TmulG1+2TmulG2+4TpTable 6
Cryptographic operations cost at the CSP.
SchemeProof generation costCRPPAcTexpG1+cTmulG1Certificateless-RDIC [62]cTexpG1+c−1TmulG1ID-RDIC [12]c+1TexpG1+c−1TmulG1+TmulG2+2TpBlockchain-RDIC [25]cTexpG1+c−1TmulG1Table 7
Cryptographic operations cost at the user.
SchemeTag generation costCRPPAbTH+2bTexpG1+bTmulG1Certificateless-RDIC [62]bTH+2bTexpG1+bTmulG1ID-RDIC [12]bTH+2bTexpG1+bTmulG1Blockchain-RDIC [25]b+3TH+2b+5TexpG1+2b+1TmulG1The valuec 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. The 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.


## 9.3. Experimentation Results

In Section9.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 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]. The cost for the tag-generation mechanism for the user can be split into two types. The 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. The 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 Quad-core Cortex-A7 mobile processor@1.6 GHz and 2 GB RAM for simulating the edge user device and edge data auditor device. The benchmark execution time in milliseconds for each cryptographic operation TH,TexpG1,TmulG1,TmulG2, and Tp 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.Table 8
Execution times of various cryptographic operations.
OperationLinux PC device (millisecond)Android mobile device (millisecond)Bilinear pairingTp3.2518.42Hash-to-element inG1TH0.66.78Multiplication inG1TmulG10.050.1Exponentiation inG1TexpG10.252.87Multiplication inG2TmulG21.458.76Figure1 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. This 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. The 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 tag-generation 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. The 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. This 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.Figure 1
Performance comparison of various computation costs of our proposed CRPPA scheme with other related schemes.Overall, from Figure1, 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]. This is because the number of major cryptographic operations, such as TH,TexpG1,TmulG1,TmulG2, and Tp, required for implementing each of the offline and online tag-generation algorithms executed by an edge user device, the proof-generation algorithm executed by the CSP, and the proof-verification algorithm executed by the data auditor in the proposed scheme and in the compared schemes is almost the same, as listed in Tables 5–7. Hence, the results confirm that the proposed protocol achieves its additional security objectives with marginal increase in the cost. Besides, the aggregate verification cost of verifying n number of audit reports by an audit-verifier in our proposed CRPPA scheme, as shown in the Verify-Proof algorithm of Section 7.2, has only 1/3rd of the computation cost required by an auditor to verify the same n number of data possession proofs.


## 10. 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. The 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 zero-knowledge 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 zero-knowledge privacy and the reliability properties of our proposed protocol. The 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.



---

*Source: 6705948-2022-02-04.xml*