Efficient Auditing Scheme for Secure Data Storage in Fog-to-Cloud Computing

Fog-to-cloud computing has now become a new cutting-edge technique along with the rapid popularity of Internet of Things (IoT). Unlike traditional cloud computing, fog-to-cloud computing needs more entities to participate in, including mobile sinks and fog nodes except for cloud service provider (CSP). Hence, the integrity auditing in fog-to-cloud storage will also be different from that of traditional cloud storage. In the recent work of Tian et al., they took the first step to design public auditing system for fog-to-cloud computing. However, their scheme becomes very inefficient since they uses intricate public key cryptographic techniques, including bilinear mapping, proof of knowledge etc. In this paper, we design a general and more efficient auditing system based on MAC and HMAC, both of which are popular private key cryptographic techniques. By implementing MAC and HMAC, we give a concrete instantiation of our auditing system. Finally, the theoretical analysis and experiment results show that our proposed system has more efficiency in terms of communication and computational costs.


I. INTRODUCTION
Fog computing, which is first proposed by Bonomi et al. in 2012 [6], has now been a popular technique for kinds of industrial fields based on Internet-of-Things (IoT) devices [15], [16], [19], [32]. As a middleware between IoT devices and clouds, fog computing nodes have their own basic computing, storage as well as resources to achieve the requirements for data preprocessing and transmission. Therefore, the model of fog-to-cloud computing emerges as an attractive solution for data storage in some resource-constraint large-scale industrial applications.
However, fog-to-cloud computing has also to face some classical problems appeared in traditional cloud computing. One of the most famous concerns is how to ensure the integrity of stored in cloud service provider (CSP). The reason is as follows. Some CSP may try to conceal the fact that some important data of IoT devices or fog nodes has been lost or corrupted due to kinds of internal or external attacks [25]. Hence, developing efficient auditing techniques for secure data storage in fog-to-cloud computing are also very necessary and significant just like in traditional cloud computing.
The associate editor coordinating the review of this manuscript and approving it for publication was Massimo Cafaro .
Although, in past years, many auditing schemes are presented for traditional cloud storage [12], [22], [25], [26], [31], [33], including many private and public auditing schemes, all of them are not directly applicable to fog-to-cloud computing for two main reasons [23], [24]. The first one is that the data from IoT is generated by various devices and hence it is inadvisable for those users (or data owners) to first retrieve these data and generate corresponding authenticators before outsourcing. The second one, which is also more important, is that the existing auditing systems do not involve fog computing nodes, which are rather crucial entities for fog-to-cloud computing because those nodes can help to efficiently process and rapidly transmit for large-scale of IoT data. Hence, it is urgent to develop new auditing techniques to ensure data's integrity for fog-to-cloud computing. In recent work of [23], Tian et al. took the first step to this direction and try to fill this gap. In fact, they designed a privacy-preserving public auditing system based on bilinear mapping and the so-called tag-transforming strategy. In addition, they also evaluated the performances of their scheme by theoretical analysis and comprehensive experiments.
It is well-known that, in public auditing scheme, the task to verify the integrity of users' data is suitable to be outsourced to another authorized third-party auditor (TPA), which may have more professional knowledge on auditing and more computational resources. However, it should also be noted that, generally speaking, public auditing systems have lower efficiencies than private ones. Just as Zhang et al. illustrated in [33], for a same data file, the time consumptions for proving, verifying and outsourcing in public auditing scheme are hundreds (or even thousands) of times of the corresponding process in their private scheme. Hence, in some pursuing-efficiency scenarios, especially for the resource-constrained mobile sinks in fog-to-cloud computing, we believe the private auditing system may be more popular. Therefore, it is also necessary and significant to design efficient private auditing schemes for the fog-to-cloud computing.
In this paper, we try to take the step to this direction. More specifically, we propose a new auditing system based on private authentication techniques: message authentication code (MAC) [14] and homomorphic MAC (HMAC) [2], [8]- [10] schemes, both of which are important primitives in cryptography. The MAC technique is used in the transmission process between mobile sinks and fog nodes while the HMAC scheme is used to verify the integrity of data blocks stored in CSP. Since a common private key is needed for the parties in MAC or HMAC when generating or verifying the tags, this model is not suitable to introduce TPA into it.
Moreover, we give a concrete instantiation of the system by instantiating the hash-based MAC scheme in [14] and the efficient HMAC scheme designed by Agrawal and Boneh in [2].
Finally, we also analyze the performances of our proposed system and compare them with that of Tian et al. as well as two related traditional cloud auditing schemes in [20] and [18]. The experiment results show that our system outperformed Tian et al.'s system in terms of communication costs and computational efficiency. Moreover, our protocol is suitable for fog-to-cloud computing and hence prior to the two schemes in [18], [20].

A. RELATED WORKS
One of the earliest work to consider the integrity of data stored in remote clouds is proof of retrievability (PoR) suggested by Jues and Kaliski [13]. In PoR, one can combine error-correcting code with spot-checking of data blocks to ensure the data's integrity. But this technique only supports a limited number of verification operations. At the same time, Ateniese et al. proposed provable data possession (PDP) based RSA-homomorphic authenticators, which can support both unlimited number of challenges and public auditing [3]. Subsequently, many works focused on the improvement of communication efficiency [4], [7], [11], [20]. Some other researches considered the dynamic update of PDP schemes [12], [22], [26], [28]. To support data dynamics, kinds of authenticated data structures are widely introduced into the public auditing schemes. For example, in 2011, Wang et al. presented the Merkle-hash-tree-based public auditing for dynamic data [26]. Later, Zhu et al. proposed a new data structure, called index hash table, to achieve data dynamics [34]. In 2017, Tian et al. further suggested a two-dimensional data structure, named dynamic hash table, to achieve both public auditing and dynamic data updating [22]. At the same year, Shen et al. proposed another novel structure, which includes a doubly linked info table and a location array, to achieve dynamic data [21].
However, few of them can be directly extended to achieve efficient and secure verification for data storage in the fog-to-cloud based IoT scenarios, although there are fruitful schemes suggested in the traditional cloud storage. The two main reasons are as follows. First, in fog-to-cloud case, the data are usually generated by various IoT devices, instead of the data owners themselves. Second, some new entities, like fog nodes, are introduced and also play important roles for processing and transmission in fog-to-cloud scenario. But in the traditional cloud storage, they are never considered. Therefore, in the recent works, Tian et al., [23] and Kashif and Mohammed [18] respectively filled this gap in the public auditing setting based on different techniques. Nevertheless, the more efficient private key auditing schemes are not considered in both papers.
As for the fog-computing, we note that, in the recent work [27], Wu et al. proposed a fog-computing-enabled cognitive network functions virtualization approach for an information-centric future Internet and also designed a communication scheme between the fog nodes and the future Internet Nodes for the forwarding process.

B. ORGANIZATIONS
The organizations of this paper are as follows. In Section 2, we introduce the background of fog-to-cloud computing as well as some preliminaries, including basic notations and primitives. In Section 3, we presented our proposed auditing system. The security analysis can be found in Section 4. In Section 5, we give a concrete instantiation of the general system presented in Section 3 and discuss the problem of keydistribution. Then we evaluate our system's performances from the aspects of communication and computational costs. Finally, conclusions can be found in Section 7.

A. SYSTEM MODEL
As shown in Fig. 1, a highly modernized company consists of many workshops, each of which is equipped with a large number of sensors, gathering the related environmental data, such as humidity, temperature as well as brightness etc.. Moreover, in each workshop, many mobile sinks are also pre-arranged at proper sites, whose actions are to collect the environment data from the sensors and transmit them to fog nodes.
Generally speaking, every fog node is a local server cluster and is able to conduct some data processing and analysis. The the original data from mobile sinks and the ''new'' generated ones are transmitted to CSP for cost-efficient storage.
In order to ensure the integrity of data, each mobile sink should compute and generate the authenticatable metadata (i.e. tag), which is bound to the original data. Then the pair of data-tag is sent to the corresponding fog node. After receiving the pair from the mobile sink, the fog node first verifies it. If it can pass the verification, then accept the original data as one block that will be stored to CSP. Otherwise, drop it and require the mobile sink to resubmit it.
Similarly, the fog node also needs to compute authenticated tags for the data blocks from mobile sinks and the pre-processed data from itself so that it is able to audit the integrity of those data after transmitting all the data and their tags to CSP.

B. BASIC NOTATIONS
In the whole paper, we denote by λ the security parameter of algorithms. For a set X , the symbol x $ ← − X means that randomly choose element x from X . For a positive number q, |q| denotes its binary length and [q] denotes the set {1, 2, . . . , q}. The symbol ·, · means that the inner-product operation of two vectors. PPT is an abbreviation of probabilistic polynomial time. A function f (λ) is called negligible if, for any c > 0, there exists a λ 0 ∈ Z such that for any λ > λ 0 , it holds that f (λ) < λ −c . Now, we list other symbols appeared in this paper as well as their definitions in Table 1.

C. PSEUDORANDOM FUNCTIONS
Now, we recall the notion of pseudorandom function (PRF). In particular, consider a set of functions from K × D to R. Denote by func(D, R) all the functions from D to R. Then f $ ← − func(D, R) means that, for x ∈ D, the value f (x) is random in R. Randomly choose a K from K and let O 0 = F(K , ·) be an oracle, which will compute and output the value F(K , x) when given the input x. Finally, for a PPT adversary A, who can make queries to the oracle O 0 or f (·), it is computational indistinguishable to decide which one it is interacting with. Since the performance of F looks like a truly random function f , we call the set consisting of F is a pseudorandom function set.

D. MESSAGE AUTHENTICATION CODE
A message authentication code (MAC) MAC consists of three PPT algorithms MAC-KeyGen, MAC, and MAC-Verify, which have the following forms.  • MAC : Take some key k and a message m ∈ {0, 1} * as inputs. Then compute a tag t for m and output it.
• MAC-Verify : Take some key k, a message m and a tag t as inputs. This algorithm will output a bit b ∈ {0, 1}. If b = 1, then accept t as a valid tag for m. Otherwise, t is not a valid tag for m. The correctness requires that, for any λ, every k ∈ {0, 1} λ and all m ∈ {0, 1} * , it holds that 1 ← MAC-Verify(k, m, MAC(k, m)).
The security requires that, any PPT adversary can generate a valid tag on a ''new'' message (i.e., a message not sent by the communicating parties) with at most negligible probability.

E. HOMOMORPHIC MAC
Informally, a homomorphic MAC scheme is an authentication technology, which allows ''legal'' users to verify the correctness of the generated tag t for a message v, which in fact is an (n + s)-dimensional vector in some finite field F q , and recompute a new tag on a combined message.
Formally, a (q, n, s) homomorphic MAC scheme consists of four PPT algorithms HMAC-KeyGen, HMAC, HCombine and HVerify, which have the following forms.
• HMAC-KeyGen : For the input λ, this algorithm generates and outputs a secret key K .
• HMAC : Take as inputs of a secret key K , an identifier id, an augmented vector v ∈ F n+s q , and j ∈ [s] indicating that v is the the j-th basis vector of the vector space identified by id. This algorithm will output a tag T for v.
• HCombine : For the inputs of ( < s) constants r 1 , . . . , r ∈ F q , vectors v 1 , . . . , v ∈ F n+s q and the corresponding tags T 1 , . . . , T , this algorithm outputs a tag T for the combined vector y := i=1 r i v i ∈ F n+s q . • HVerify : For the inputs of a secret key K , an identifier id, a vector y ∈ F n+m q and a tag T , this algorithm outputs 0 (reject) or 1 (accept). The correctness requires that, for any secret key K , r 1 , . . . , r ∈ F q , The security requires that any PPT attacker, obtaining the signatures on arbitrary vector spaces of its choice, is not able to give a valid triple (id, y, T ), where id is new, or equals to some identifier id i that it had obtained the corresponding signature but y does not belong to the space identified by id i .

III. THE PROPOSED AUDITING SYSTEM
In this section, we present our general auditing system for fog-to-cloud computing based on a MAC scheme and a (q, n, s) homomorphic MAC scheme HMAC = (HMAC-KeyGen, HMAC, HCombine, HVerify).
In fact, the whole system mainly includes six PPT algorithms: a key-generation algorithm KeyGen, a tag-generation algorithm for mobile sinks TagGenMS, a tag-generation algorithm for fog nodes TagGenFN, a challenge-generation algorithm ChalGen, a proof-generation algorithm ProofGen and a verification algorithm Verify. All the entities are equipped with those algorithms as follows.
• A key generation center (KGC) 1 runs the key-generation algorithm to obtain some keys and distributes them to the entities in the system, including s 1 mobile sinks, f fog nodes and CSP.
• After obtaining a distributed key from KGC, each mobile sink MS i,j runs the algorithm TagGenMS, which in fact consists of the authentication algorithm of a MAC scheme, to generate an authenticated tag t i,j for its data block m i,j ∈ F n q and transmits the pair (m i,j , t i,j ) to its fog node F i .
• Then the fog node F i will first check the correctness of the transmitted pair (m i,j , t i,j ) by using the verification algorithm MAC-Verify of the same MAC scheme based on the common key k i,j , which is also distributed by KGC. If it can not pass the verification, then drop it and require the mobile sink to resubmit a new pair. Else, discard the tag t i,j and only save the data block m i,j . Meanwhile, the fog node is also allowed to make analysis on the data blocks collected from all the mobile sinks and hence generates new data blocks denoted by m i,s 1 +1 , m i,s 1 +2 , . . . , m i,s . For all the data blocks m i,1 , m i,2 , . . . , m i,s , the fog node F i binds them into an intact file with filename ID i , and respectively computes tags for each block by running TagGenFN, which in fact is a homomorphic MAC algorithm, based on another key K i , and submits all the data-tag pairs to CSP for secure storage.
• If some fog node wants to check the integrity of its data blocks, it can run ChalGen to obtain a challenge message chal and gives them to CSP.
• Now, CSP can run ProofGen to get a related proof based on the storage data blocks and returns it to the fog node.
• Finally, the fog node can check the response by running Verify based on the same key K i , which is also distributed by KGC. Specifically, the six algorithms included in the above system are described as follows.
• KeyGen : The key generation algorithm takes the security parameter λ as its input and will generate keys for all the entities except for CSP in the system.
The j-th mobile sink MS i,j for the i-th fog node F i , who gets the keys k i and K i , will obtain the key k i,j . That is, all the keys of the mobile sinks corresponding to some fog node are also shared by this fog node. 2 • TagGenMS : The tag generation algorithm for mobile sinks takes data block and a MAC-key as inputs, and will output a tag under the MAC-key for this data block. Concretely, for the data block m i,j ∈ F n q collected by the mobile sink MS i,j , this algorithm computes and outputs it.
• TagGenFN : This algorithm is run by fog nodes, which takes a HMAC-key K i , an identifier ID i , data block m i,j ∈ F n q and an index j as inputs, and will output a tag under the HMAC-key of some fog node for this data block. Specifically, for the data block m i,j , this algorithm first augments it as Then compute and output the tag • ChalGen : This algorithm generates the challenge messages for each fog nodes. In particular, for the input of parameter , it randomly chooses different indices 1 ≤ j 1 < j 2 < · · · < j ≤ s as well as coefficients r 1 , . . . , r ∈ F q . Denote by chal the set of challenge messages r 1 ), . . . , (j , r )} and output it.
• ProofGen : Once receiving the challenge chal from the i-th fog node F i , the CSP first parses chal as r 1 ), . . . , (j , r )} .
Then run Denote by the proof of (v, T ) and return it to the corresponding fog node F i .
• Verify : When receiving the returned proof , the fog node F i first parses as (v, T ) and runs b ← HVerify(K i , ID i , v, T ).
If b = 1, then it thinks that its original data blocks are still securely stored in CSP. Else if b = 0, then the integrity of those blocks is broken.

IV. SECURITY ANALYSIS
In this section, we analyze the security of our proposed system in Section III, which can be divided into two cases: data security from mobile sinks to fog node and data integrity from fog node to CSP.

A. DATA SECURITY FROM MOBILE SINKS TO FOG NODE
Theorem 1: If MAC is a secure MAC scheme, then the transmission of data blocks from mobile sinks to fog node is secure. Proof: For the i-th fog node F i , who has the MAC-key it shares the key k i,j (1 ≤ j ≤ s 1 ) with the j-th mobile sink MS i,j . Consider a PPT adversary A, who does not know the key k i,j but intends to denote MS i,j and submit a forged message-tag pair (m, t) to the fog node F i . If it can pass the verification of fog node, that is, then this (m, t) is just a successful forgery for the MAC scheme MAC. Therefore, according to the security of MAC, we know that any ''illegal'' PPT adversary can not generate a valid message-tag pair with non-negligible probability. That is, the transmission process of data blocks from mobile sinks to the corresponding fog node is secure.

B. DATA INTEGRITY FROM FOG NODE TO CSP
Theorem 2: If HMAC is a secure HMAC scheme, then the data integrity (stored in CSP) for the system presented in Section III can be guaranteed. Proof: To respond to the challenge message r 1 ), . . . , (j , r )} from the i-th fog node, the CSP needs to compute the proof as Therefore, we only need to consider the unforgeability of . If some block m i,j 0 (or its augmented vector v i,j 0 ) is not securely stored in CSP, then the randomly chosen indices j 1 , j 2 , . . . , j include j 0 with probability /s. Meanwhile, CSP can also not generate a correct proof from (1). Hence, the CSP has to return a forged proof = (v , T ) without using m i,j 0 (or v i,j 0 ). According to the security of HMAC, we know that the forged proof can pass the verification of HVerify with at most negligible probability. VOLUME 9, 2021 As a result, the fog node F i accepts this proof (i.e. running Verify(K i , v , T ) and obtaining the output 1) with also negligible probability. Hence, the data integrity from fog node to CSP for our proposed system is hold if the underlying HMAC scheme HMAC is secure.

V. A CONCRETE INSTANTIATION AND SOME DISCUSSIONS A. A CONCRETE INSTANTIATION
In this subsection, we give a concrete instantiation for our proposed system presented in Section III by instantiating the MAC and HMAC schemes. In particular, we choose the hash-based MAC scheme in [14] and the HMAC scheme proposed by Agrawal and Boneh in [2]. Then the concrete instantiations of the six algorithms are as follows.
The j-th mobile sink MS i,j for the i-th fog node F i , who gets the keys k i and K i , will obtain the key k i,j .
• TagGenMS : For the data block m i,j ∈ F n q collected by the mobile sink MS i,j , this algorithm computes in which H is a standard hash function, IV is an arbitrary fixed initial vector, opad is formed by repeating the byte 36 in hexadecimal as many times as needed and the string ipad is formed in the same way using the the byte 5C. Output t i,j as the tag of the data block m i,j .
• TagGenFN : This algorithm is run by fog nodes, which takes a HMAC-key an identifier ID i , data block m i,j ∈ F n q and an index j as inputs. For the data block m i,j , this algorithm first augments it as Then compute and output the tag • ChalGen : Same as ChalGen.
• ProofGen : Once receiving the challenge chal from the i-th fog node F i , the CSP first parses chal as r 1 ), . . . , (j , r )} .

Then compute
Finally, output the proof = (v, T ).
• Verify : When receiving the returned proof , the fog node F i first parses as (v, T ) and computes where v n+j is the (n + j)-th component of v. If T i,j = T i,j , then output 1. Otherwise, output 0. In addition, we remark that the fog node F i will check the correctness of the pair (m i,j , t i,j ) transmitted from the mobile sink MS i,j as follows. Compute and check if t i,j = t i,j . If it is not, drop it and require the mobile sink to resubmit a new pair. Otherwise, discard the tag t i,j and continue to do the next steps.

B. KEY-DISTRIBUTION
Note that in the concrete instantiation presented in Section V-A, each mobile sink owns a key k i,j ∈ {0, 1} λ . But each fog node F i will be distributed s 1 MAC-keys k i,1 , . . . , k i,s 1 and a HMAC-key Therefore, the distribution of keys for all the entities (especially for fog nodes) becomes a heavy work in our proposed system. In this subsection, we adopt cryptographic PRF to change the situations and try to alleviate the heavy task of key-distribution.
Distribute k i,j to its j-th mobile sink (corresponding to F i ) while keeping as its own HMAC-key.

C. DYNAMIC UPDATE AND PREVENTING REPLAY ATTACKS
In this subsection, we discuss the problem of dynamic update and security against replay attacks for our proposed protocol, which is based on the key-distribution technique discussed in Section V-B. Here, we adopt the map-version table T , which is a small data structure on the verifier side (i.e. fog nodes F i 's) to record the update information and proposed by Barsoum and Hasan in [5]. Concretely, the mapversion table consists of three columns: Serial number SN (i) , block number j, and block version BV (i) . The serial number is an indexing to the file blocks and indicating the physical position of a block in a data file. The block number is a counter used to make a logical indexing to the file blocks and the block version indicates the current versions of the file block. If a specific block is updated, then its BV (i) is incremented by 1.

1) DYNAMIC UPDATE
To support dynamic update, the original key-generation in (3) will be further changed as When the i-th fog node F i wanting to dynamic update the outsourced blocks, it sends a request in the form: where ID i is F i 's identity, BlockOp corresponds to block modification (denoted by BM), block insertion (BI), or block deletion (BD), and (m * i,j , T * i,j ) is the new block-tag pair computed as follows.
• Block Modification. First update BV (i) = BV (i) + 1 in the map-version table T and compute Upon receiving the request, the CSP replaces m i,j with m * i,j and T i,j with T * i,j . • Block Insertion. If F i wants to insert a new block m * i into the outsourced data file, it first defines SN = SN max + 1, BN = BN max + 1, BV (i) = 1, where SN max and BN max are respectively current maximum of serial and block numbers, and generates the tag T * i as in (5). Upon receiving this request, the CSP adds (m * , T * i ) into the data file outsouced by F i .
• Block Deletion. The deletion request is the form ID i , BD, j, null, null . The map-version table T is updated by deleting the j-th item and the CSP deletes the j-th data-tag pair. When verifying the returned proof from CSP, which is based on some challenge message chal, the fog node F i looks up T and finds out the block information (j 1 , . . . , j ) as well as the block version (BV (i) j 1 , . . . , BV (i) j ). Then re-compute b i,j according to (4) and continue the next steps in the algorithm Verify .
Obviously, the additional operations to support dynamic update only consist of an appended map-version table and an additional input for F 1 . Therefore, in terms of communication and computational costs, it does not affect efficiency.

2) PREVENTING REPLAY ATTACKS
Here, we discuss the security of preventing replaying attacks for our concrete instantiation protocol in the above Subsection. Of course, in order to obtain security against replay attack, we need further modify (4) as where Time i,j denotes the time stamp generating b i,j . Then we have Theorem 3: If H is a secure hash function, then the modified protocol of Section V-A (according to (6)) is secure against replay attacks.
Proof. Recall that the replay attack means that a part of the returned proof from CSP, which is based on some challenge message chal = {(j 1 , r 1 ), . . . , (j , r )} , may be replaced by some previous data information. Without loss of generality, we assume that the first block's information is replaced by its former block v * i,j 1 as well as the corresponding tag T 68 i,j 1 . In other words, the CSP computes its proof * According to the equation (2) in the algorithm of Verify , we know that this * can pass the verification with at most negligible probability if the time stamp is considered.

VI. PERFORMANCE EVALUATIONS
In this section, we make the performance analysis on our concrete instantiation for the system in Section V-A in terms of communication and computational costs. In fact, we choose three classical and related protocols: [20], [23], and [18], and compare the performances of them with our proposed one. We remark that, in [20], Shacham and Waters proposed one private key protocol and another public key verification protocol for traditional cloud storage, respectively. Meanwhile, the proposed protocol by Munir and Mohammed in [18] is almost same as the public key verification one in [20]. However, as we said in the part of Introduction, the existing authentication protocols for traditional cloud storage can not be directly used to fog-to-cloud computing and do not consider how the mobile sinks securely transmit data to fog nodes. For convenience to compare, the fog node is seen as the data owner in traditional cloud auditing.

A. COMMUNICATION COSTS 1) MOBILE SINK TO FOG NODE (MStoFG)
In the process of transmission from mobile sink to fog node, each mobile sink MS i,j needs to compute a MAC-tag t i,j for VOLUME 9, 2021 its data block m i,j and transmit the data-tag pair (m i,j , t i,j ) to fog node. Hence, the communication overhead for this process is the length of the tag t i,j (i.e. |t i,j |), which in fact is the length of the chosen hash function H (denoted by |H |). Accordingly, the tag t i,j in [23] consists of an element in the basis group G and hence, it communication overhead for this process is |G|. In addition, since in the systems of [20] and [18], the process of transmitting from mobile sink to fog node is not considered, the communication costs from mobile sink to fog node for both protocols are null.
If the fog nodes are seen as the data owners in traditional cloud storage, then for total s data blocks m 1 , . . . , m s , the communication overheads for [20] and [18] are also the generated tags for all the data blocks, which respectively equal to s · |F q | and s · |G|.
Similarly, both the communication costs from data owners in [20] and [18] equal to equal to · (|s| + |F q |).

4) RESPONSES FROM CSP TO FOG NODE (ReCSPtoFN)
After receiving a challenge message chal from fog node (or TPA in [23]), the CSP will compute and return a proof based on this chal as well as the stored data-tag pairs. Hence, the communication cost in our system equals to the length of = (v, T ) ∈ F n+s q × F q (i.e. | | = (n + s + 1) · F q ). Accordingly, the proof in [23] consists of an element ∈ G 1 and hence its communication cost is |G 1 | = |G|. In addition, we can compute the length of the responses from CSP to the verifier (i.e. fog nodes or TPA) in [20] and [18] respectively equal to 2 · |F q | and |F q | + |G|.
All the comparisons of communication costs for the four protocols are summarized in Table 2, where ''×'' denotes the corresponding item is not considered.

B. COMPUTATIONAL COSTS
Now, we consider the computational costs of our system. In particular, we set the parameter q as 2 8 so that each element in F q can be represented in 1 Byte. Let n = 1024 and hence each data block m i,j has size of 1024 Bytes (i.e. 1 M). In addition, we choose s 1 = 100, s = 150, which means that each fog node will obtain 100 data blocks from 100 mobile sinks and it will generate 50 additional blocks.
Since Tian et al.'s system is based on different techniques from ours, we can not instantiate them in a same frame. But all the experiments are done based on the same hardwire device. That is, a laptop with the configuration of Intel(R) Core(TM) i7-7500 CPU 2.7GHz 2.9 GHz and 8 GB RAM. The experiment on our system is run in Matlab with version R2014a since all the computations consist of linear operations of vectors. We also implement Tian et al.'s system within the framework of ''Charm'' [1] and choose the 512-bit SS elliptic curve from pairing-based cryptography library [17] as the basis of whole scheme. Then the running time for all the processes are listed in the Table 3. We remark that, in Table 3, TagGenMS' is the tag-generation algorithm for single data block, which is run by mobile sink. TagGenFN is the tag-generation algorithm for 150 data blocks. FG-Verify1 denotes fog node's verification of data-tag pairs transmitted from 100 mobile sinks while FG-Verify2 means the verification on the CSP's response. In [23], the check of CSP's response is done by TPA. However, in our system, the fog node verifies it. Finally, ChalGen and ProofGen are respectively the generations of challenge messages for FG (or TPA in Tian et al.'s scheme) and proof for CSP.
In addition, we also implement the two traditional auditing schemes in [20] and [18] based on the same hardwire devices and software platform, respectively. Still note that, there are not mobile sinks in traditional cloud storage and hence the running time of TagGenMS and FG-Verify1 is null, which is denoted by '' × '' in Table 3.
From Table 3, we know that our proposed system obviously outperforms that of Tian et al. in terms of computational efficiency. Moreover, our protocol is suitable for fog-to-cloud computing and hence prior to the two schemes in [18], [20], which are designed only for traditional cloud storage.

VII. CONCLUSION
In this paper, we propose an efficient auditing system for fog-to-cloud computing. Although our system is not public auditing, it obviously outperforms the one proposed by Tian et al. in terms of communication and computational efficiencies. The simulation results illustrate the computational efficiency. We believe that our proposed system must be an interesting choice for securely storage of data in fog-to-cloud computing.