Cloud auditing for outsourced storage service in healthcare systems with static data transfer

1.   Introduction

Healthcare systems have the advantages of convenience and long-term data storage. In addition, the medical data can help doctors and health consultants analyze and keep track of the patients' health status. Healthcare data mining has many potential applications in not only theoretical studies, but also in various aspects, such as disease diagnosing, medicine development, and illness detection ^[1]. Different kinds of healthcare data may get involved in further analyses like health check data and daily body monitoring data. Moreover, many health statuses can be measured by various wearable devices. Taking the resource-limited property of these devices into consideration, the health data needs to be uploaded to medical centers or hospitals. For centralized management and to release the burden of establishing and maintaining data storage infrastructure in each medical center or hospital, these data can be stored at central servers. This can save costs for the data owners and guarantee conveniences for doctors and health consultants to reviewing data. The system users (patients, doctors, consultants, etc.) or data owners (hospitals, medical centers, etc.) do not need to store or maintain the data in their local devices.

Security is one of the issues people are most concerned about regarding outsourced data ^[2]. Integrity is one of the most fundamental security requirements in information systems. In particular, the precise value of healthcare data is important for diagnoses, data analyses, medicine evaluation etc. and can cause severe consequences if the integrity is not guaranteed. Many techniques exist to achieve data integrity. As for outsourced data, cloud auditing is the most commonly adopted method. In such a system (e.g., healthcare system), users' electronic health records (EHRs) are remotely stored on the server, and the data integrity can be verified through an auditing process. The auditing process is an interactive process that consists of a challenge phase and a response phase. It can be undertaken between the data owner and the storage server, or between a third-party auditor (TPA) and the server. As discussed before, an intended established party that deals with the auditing requests from data owners is preferred.

The basic idea of data auditing is composed of a challenge-response interaction between the cloud server and TPA. The data owner first generates a tag for each data block and uploads the data together with the tag to the server. Then, the TPA can launch an auditing task on behalf of the data owner by sending the server a challenge. Next, the server computes the correct response according to the challenge with valid data-tag pairs and returns the response. After receiving the response, the TPA verifies its validness and provides the data owner the results.

1.1.   Data transfer in outsourced storage systems

In practice, the data can be transferred frequently in the system. For example, when a patient changes the hospital or a client signs a contract with new insurance company, the user's personal EHRs should be transferred from the original data owner to the new data owner. Taking all the aforementioned situations into consideration, the system framework of a cloud auditing scheme for healthcare systems consists of four basic components, namely the system user, data owner, cloud server, and TPA, as shown in Figure 1. The system user generates EHRs at the hospital or medical organizations and enjoys the services. The hospital or medical organizations control the users' data and serves as data owner on behalf of its clients according to relevant laws and regulations. The cloud server and TPA provide the outsourced storage and auditing functionality as traditional cloud platform. The core requirement in the system is how to maintain efficiency during data transfer process when the data is frequently transferred among data owners.

As for the real-world cases of transfer for healthcare data, examples include patient transmission, coordinating treatment, remote consultation, disease surveillance etc. Many public datasets or open sources are available, such as global data like Global Health Observatory (GHO), Global Burden of Disease (GBD), Johns Hopkins COVID-19 Dashboard, Global Health Data Exchange (GHDx); regional data like European Center for Disease Prevention and Control (ECDC), American CDC WONDER; and open source data like Kaggle Health Datasets. According to the public information, the data size of the aforementioned cases ranges from 1 GB to 30 PB. Even a single subset or the data of one indicator, e.g., a GBD subset for medical research may reach 10 GB. The transfer for such size data requires heavy costs. Efficient construction not only has theoretical benefits but also enjoys advantages in practical implementations, such as energy saving ^[3].

A straightforward approach for cloud auditing with data transfer is to recompute the corresponding tags by the new data owner and conduct auditing tasks with the new data owner's public key after the transfer process. However, this causes heavy computational burden for the data owner and requires complete download and upload operations, which also brings heavy transmission costs. An alternative method is to move the computational operations to the server side. The original owner generates a token and uploads the token to the server, then the server can update the tag. The updated tag is equivalent to the tag that generated by the new owner. The basic idea in dealing with the tag is similar to proxy re-signature technique ^[4], and the remaining auditing processes are the same. The outline of traditional cloud auditing that supports data transfer is shown in Figure 2. The concept of data ownership transfer was proposed by Shen et al. ^[5] and extended by follow-up researches, including multi-ownership transfer ^[6], threshold transfer ^[7], and in the certificateless cryptography setting ^[8]. Other related schemes, such as designated ownership transfer ^[9], E-Health data transfer ^[10], block-chain based transfer ^[11], anonymous transfer ^[12], and in the IoT setting ^[13], are also available in the literature.

Despite the basic functionality provided by current transfer techniques, heavy computational cost occurs either at the owner side or the server side when the data transfer operation take places. If the system has frequent data transfer requirements, such as in a healthcare system, it brings heavy burden to the system. How to reduce the overall computational cost is an essential factor in improving the system efficiency.

Efficiency issues. As discussed, frequent data (together with the ownership) transfer can cause heavy computation and transmission burdens. In this paper, we attempt to remove these operations by keeping the tag unchanged during the transfer process. Therefore, both the aforementioned two costs can be relieved. To achieve this goal, we modify the transfer process as follows: The token is sent to the new data owner instead of the server, and the auditing request is generated by the token and new owner's public key. The TPA also updates the challenge with the auditing request from a new owner. Then, the server computes the response with the unchanged data and tag. As a result, the response computed with the updated challenge can be verified using the new owner's public key. Since there is no need to change the data or tag on both the owner and the server side, we refer to this process as static transfer. The technical overview is summarized in Figure 3. Please note that when the data owner changes during transfer, the challenge-response phases also need to be modified. Otherwise, the response computed by the same data and tag cannot be verified by the new owner's public key. According to Figures 2 and 3, the advantages of static data transfer can be summarized as Table 1.

In particular, the improvement with respect to end-to-end system latency and throughput in large-scale systems can be quite substantial. For instance, the Global Health Observatory (GHO) database contains 10 GB total data amount with a 100 MB size single dataset for a certain research purpose. According to the simulation result (with a laptop computer) in Section 4.3, the size of a block is 64 Byte, the computation cost of tag generation, response, and verification for each block is around 0.04 s, 0.04 s, and 0.01 s, respectively. A single dataset (100 MB) consists of roughly 1.5 million blocks, and taking the challenge ratio as 1%, the number of challenged block is 15 k. The end-to-end system latency between the TPA and server (with respect to challenge-response interaction) takes more than 600 seconds, while the latency between new data owner and the server (with respect to recompute & reupload operations) takes more than 16 hours with additional double throughput occupation.

1.2.   Related work

There are two branches of data auditing following the above idea, namely the proof of data possession (PDP) by Ateniese et al. (ACM CCS 2007) ^[14] and proof of retrievability (PoR) by Juels and Kaliski (ACM CCS 2007) ^[15]. Later, Shacham and Waters (Asiacrypt 2008) ^[16] proposed an improved PoR scheme that supports arbitrary number of auditing. Many following studies ^{[17,18,19,20,21,22,23,24,25]} and other further improvements extended from these studies are currently available in the literature. In ^[18], Ateniese et al. first considered scalable PDP, which supports data update operations. Later, Erway et al. ^[26] introduced dynamic PDP that allows insert, update, and delete operations. Other dynamic auditing schemes can be found in ^[27,28,29]. Data auditing with multi-replicas ^[20] was proposed to increase data retrieving probability and further improved by Armknecht et al. ^[30]. As for the auditing schemes in the identity-based settings, ^{[22,31,32,33]} are introduced with different motivations; Li et al. ^[34] presented a fuzzy identity-based auditing scheme; examples of attribute-based auditing are ^[35,36]. Shen and Tzeng ^[37] achieved delegatable PDP, where the data owner can grant auditing power to an auditor it identifies. More efficient delegatable constructions ^[38,39] with lightweight tag generations are proposed. Post-quantum auditing schemes can be found in ^[40,41,42].

As shown, two popular constructions that work as the underlying building blocks are available among most cloud auditing schemes. In ^[14], the tag is similar to a RSA-type signature, and the ratio of data size to tag size can be $n:1$ for a proper parameter $n$. It has high storage efficiency; however, the size of response is not compact enough since it is mainly a RSA-type signature. On the other hand, the tag in ^[16] is similar to a BLS-type signature, and the size of the response is compact. Nevertheless, the tag cannot be compressed in a straightforward way and so the ratio of data size to tag size is $1:1$. The storage efficiency can achieve $50\%$ at most. Since these two constructions have been proposed, it seems that an inherent tradeoff between storage and response size is inevitable, and we can choose only one aspect to improve efficiency. Until recently, a revolutionary technique named evolution tag was introduced in ^[43] to solve the aforementioned problem. It achieved high storage efficiency and compact response simultaneously for the first time.

1.3.   Motivation and contribution

Static data transfer has efficient transfer process since no change on data or tag is required. However, the BLS-type auditing structure faces the storage efficiency problem. Moreover, the evolution tag technique ^[43] can improve storage efficiency but cannot be directly applied to support data transfer. In the healthcare systems, a patient may often transfer from one hospital to another; or the experimental data needs to be transferred to the next medical center in a joint medicine development procedure. There is much data that is involved in transfers. On one hand, efficient transfer is preferred to relieve the system computational burden. On the other hand, the storage efficiency is another aspect that we should pay attention to. As illustrated above, static data transfer requires less computation during the transfer process; while evolution tag can improve storage efficiency by aggregating tags. Coincidentally, both the two techniques are based on the HLA structure. We can combine these two techniques to achieve static data transfer and aggregated tags simultaneously.

In this paper, we show how to combine the static data transfer with the evolution tag technique. It is feasible because the two structures both rely on the BLS-type structure. By elaborately designing the transfer token, the tags can be aggregated and then extracted as evolution tags before or after data transfer. There is no extra computations or transmissions during the challenge and response phases. The major contributions of this paper are summarized as follows.

$1)$ We first present the basic scheme for cloud auditing that supports static data transfer. The transfer token is introduced and the challenge phase needs to update. Neither the data nor the tags need to change during data transfer process.

$2)$ To further improve storage efficiency, we combine the static data transfer with evolution tag technique. The definitions of static data transfer and the corresponding threat model are proposed.

$3)$ We put forward a concrete construction of static data transfer auditing. The efficiency with respect to public key, tag, challenge, and response is comparable with other schemes.

1.4.   Organization

The rest of this paper is organized as follows. In Section 2, we review some mathematical preliminaries, including homomorphic linear authenticator (HLA) and hardness assumption. Then, we give the definition of static data transfer auditing and the corresponding threat model in Section 3. Next, our concrete construction is presented in Section 4, together with the security and efficiency analysis. Finally, the conclusion part comes in Section 5.

2.   Preliminaries

2.1.   Homomorphic linear authenticator (HLA)

The core construction of homomorphic linear authenticator (HLA) in ^[16] is as follows.

${\sf Parameter.}$ The public parameter includes pairing groups $(\mathbb{G}_1, \mathbb{G}_2, \mathbb{G}_T, p, e, g_1, h_2)$ and hash function $H$, with $g_1\in \mathbb{G}_1, h_2\in \mathbb{G}_2, e:\mathbb{G}_1\times \mathbb{G}_2\rightarrow \mathbb{G}_T$. The pairing has an isomorphism $\psi:\mathbb{G}_2\rightarrow \mathbb{G}_1$ and $g_1 = \psi(h_2)$.

${\sf Key structure.}$ The public and secret key pair is $pk = h_2^a, sk = a$ for $a\in \mathbb{Z}_p$.

${\sf Tag structure.}$ A message $M$ with file name $f$, parse $M$ into $(m_1, m_2, \dots)$, where $m_i\in \mathbb{Z}_p$ to be stored at index $i$ and the tag is

${\sf Challenge structure.}$ Choose a set of indexes $I$, randomly pick $r_i\in \mathbb{Z}_p$ for each $i\in I$, and the challenge is $chal = \{(i, r_i)\}$.

${\sf Response structure.}$ For each $i\in chal$, find the message $m_i$ and tag $t_i$, then compute

The response is $res = (\mu, \sigma)$.

2.2.   HLA with evolution tag

The core idea to improve storage efficiency in the homomorphic linear authenticator (HLA) is to aggregate tags into an aggregated tag; and then "recover'' tags from the aggregated tag for computing response. Please note that we cannot simply recover the original tags from the aggregated tags since the entropy of an aggregated tag is much smaller than the original tags. This is the reason why evolution tag is introduced and the evolution tags are the real input to compute responses. The innovation of utilizing evolution tags paved the way to achieving high storage efficiency and does not sacrifice the size of response. The comparison between the traditional HLA and evolution tag technique is shown in Figure 4. The underlying structures are both BLS-type. The sketch of evolution tag technique is described as follows.

${\sf Parameter.}$ The public parameter is the same as the scheme in ^[16] with an additional hash function $H_2:\{0, 1\}^*\rightarrow \mathbb{Z}_p$ and a parameter $n$. This parameter determines the size of public and secret key pair and the storage efficiency.

${\sf Key structure.}$ The public and secret key pair is

${\sf Tag structure.}$ For a message $M$ with file name $f$, parse $M$ into $(m_1, m_2, \dots)$, where $m_i\in \mathbb{Z}_p$ to be stored at index $i$. First, compute $i = j\cdot n+k$, where $k\in [1, n]$^*. The tag is

^*Please note the integer $k$ must between $1$ to $n$, which is similar to the modular operation but different when $n | i$ since $k$ cannot be $0$ but can be $n$. To be more specific, $k$ can be defined as $k = \begin{cases}n, \text{ if }n|i, \\i \text{ mod }n, \text{ if }n\nmid i.\end{cases}$

Then, aggregate every $n$ tags into one aggregated tag $T_1 = \prod\limits_{l = 1}^n t_l, T_2 = \prod\limits_{l = n+1}^{2n} t_l, \dots$ and these aggregated tags $\{T_j\}$ will be uploaded.

${\sf Challenge structure.}$ Choose a set of indexes $I$, randomly pick $c\in \mathbb{Z}_p$ and $r_i\in \mathbb{Z}_p$ for each $i\in I$. Compute $(h_2^{ca}, h_2^{ca^2}, \dots, h_2^{ca^n}, h_2^{ca^{n+2}}, \dots, h_2^{ca^{2n}})$ and the challenge is

Please note the item $h_2^{ca^{n+1}}$ serves as the secret value and is not included in the challenge.

${\sf Response structure.}$ For each $i\in chal$, find the message $m_i$ and the aggregated tag $T_{j+1}$ that includes $t_i$. Then, compute the evolution tag

Next, compute $\mu = \sum\limits_{(i, r_i)\in chal} m_i \cdot r_i\ \text{mod }p, \sigma = \prod\limits_{(i, r_i)\in chal} e_i^{r_i}$ and the response is $res = (\mu, \sigma)$.

2.3.   HLA with static data transfer

In this section, we first sketch the core idea to achieve static transfer. The data and tags remain "static" because the token is directly given from the original data owner to the new data owner. Moreover, the challenge algorithm is updated if the auditing request is launched by a new data owner. To achieve this goal, the token generation algorithm is added. Namely, the original owner A $(pk_A = h_2^a, sk_A = a)$ computes the transfer token $tk_{A\rightarrow B}$ with its secret key $a$ and the new owner B's public key $pk_B = h_2^b$, where the token $tk_{A\rightarrow B} = h_2^{\frac{b}{a}}$. Then, the original owner gives the token to the new owner. The new owner can send the auditing request with the token $tk_{A\rightarrow B}$ to the TPA. The token can also be verified by checking whether the equation $e(\psi(tk_{A\rightarrow B}), pk_A) = e(g_1, pk_B)$ holds. On the other hand, the challenge and response phases also need to update to support data transfer.

As analyzed, the static transfer process is guaranteed because the challenge phase is updated with the public key and token of the new data owner. Consequently, the difference between auditing before and after data transfer is implicitly conducted by distinguishing the challenge generation. Next, we give the description of the concrete construction as the basic scheme in this paper to illustrate how static transfer is obtained.

${\sf Parameter.}$ The public parameter includes pairing groups $(\mathbb{G}_1, \mathbb{G}_2, \mathbb{G}_T, p, e, g_1, h_2)$ and hash function $H$, with $g_1\in \mathbb{G}_1, h_2\in \mathbb{G}_2, e:\mathbb{G}_1\times \mathbb{G}_2\rightarrow \mathbb{G}_T$. The pairing has an isomorphism $\psi:\mathbb{G}_2\rightarrow \mathbb{G}_1$ and $g_1 = \psi(h_2)$.

${\sf Key structure.}$ The public and secret key pair is $pk = h_2^a, sk = a$ for $a\in \mathbb{Z}_p$.

${\sf Tag structure.}$ For a message $M$ with file name $f$, parse $M$ into $(m_1, m_2, \dots)$, where $m_i\in \mathbb{Z}_p$ to be stored at index $i$ and the tag is

${\sf Token structure.}$ The transfer token $tk_{A\rightarrow B}$ from the original owner A $(pk_A = h_2^a, sk_A = a)$ to new owner B $(pk_B = h_2^b)$ is $tk_{A\rightarrow B} = h_2^{\frac{b}{a}}$.

${\sf Challenge structure.}$ Choose a set of indexes $I$, randomly pick $r_i\in \mathbb{Z}_p$ For each $i\in I$, and the challenge is further divided as

● For data before transfer, pick a random $c\in \mathbb{Z}_p$, compute $cpk = h_2^{c}$ and $s = h_2^{ac}$ with $pk_A = h_2^a$;

● For data after transfer, pick a random $c\in \mathbb{Z}_p$, compute $cpk = h_2^{\frac{bc}{a}}$ and $s = h_2^{bc}$ with $tk_{A\rightarrow B} = h_2^{\frac{b}{a}}$ and $pk_B = h_2^b$.

The challenge is $chal = (\{(i, r_i)\}, cpk)$, and the value $s$ is kept secret for verifying the response.

${\sf Response structure.}$ For each $i\in chal$, find the message $m_i$ and tag $t_i$, compute

The response is $res = (\mu, \sigma)$.

${\sf Verification structure.}$ Given response $res = (\mu, \sigma)$ and the secret value $s$, check whether the equation $\sigma = e\left(\prod\limits_{(i, r_i)\in chal} H(f||i)^{r_i}\cdot g_1^{\mu}, s\right)$ holds.

Our basic scheme can be seen as the combination of the Shacham-Waters auditing scheme ^[16] with an additional token generation algorithm. To make it easier for comprehension, we give the comparison of scheme constructions in Figure 5.

Next, we summarize the core structures in HLA, evolution tag, and static data transfer in Table 2.

2.4.   Hardness assumption

In ^[44], Boneh et al. defined the Bilinear Diffie-Hellman Exponent (BDHE) problem for the pairing group $\mathbb{G}$ in a symmetric pairing $e:\mathbb{G}\times \mathbb{G}\rightarrow \mathbb{G}_T$. The detailed definition comes as follows.

Definition 1 (Bilinear Diffie-Hellman Exponent (BDHE) Problem) Given the following instances

the BDHE problem is to compute $e(g, h)^{a^{n}}\in \mathbb{G}_T$.

Based on the above definition, the $n$-General Diffie-Hellman Exponent ($n$-GDHE) problem was introduced in ^[43] for $(\mathbb{G}_1, \mathbb{G}_2, \mathbb{G}_T, p, e, g_1, h_2)$, where $g_1\in \mathbb{G}_1, h_2\in \mathbb{G}_2$ and $e:\mathbb{G}_1\times \mathbb{G}_2\rightarrow \mathbb{G}_T$.

Definition 2 ($n$-General Diffie-Hellman Exponent ($n$-GDHE) Problem) Given the following instances

the $n$-GDHE problem is to compute $e(g_1^r, h_2)^{ca^{n+1}}$.

We say an algorithm $\mathcal{A}$ has advantage $\epsilon$ in solving the $n$-GDHE problem if

The $n$-GDHE assumption holds in pairing groups $(\mathbb{G}_1, \mathbb{G}_2, \mathbb{G}_T)$, if no P.P.T. algorithm that runs within time $t$ has advantage $\epsilon$ in solving the $n$-GDHE problem.

3.   Definition and security model

3.1.   Scheme definition

A cloud auditing scheme with static data transfer is composed of the following seven algorithms.

${\sf Setup}$ $(1^\kappa, n)\rightarrow params$: The setup algorithm is run by the system organizer. It inputs the security parameter $1^\kappa$ and a parameter $n$, which determines the data storage efficiency, and outputs the system public parameter $params$.

${\sf KeyGen}$ $(params)\rightarrow (pk, sk)$: The key generation algorithm is run by a user in the system. It inputs the system public parameter $params$ and outputs a pair of public and secret key $(pk, sk)$ for the user.

${\sf TokenGen}$ $(params, sk_A, pk_B)\rightarrow tk_{A\rightarrow B}$: The transfer token generation algorithm is run by the original data owner. It inputs the system public parameter $params$, the original data owner's secret key $sk_A$, and the new owner's public key $pk_B$, and outputs a transfer token $tk_{A\rightarrow B}$.

${\sf TagGen}$ $(params, sk, M)\rightarrow T$: The tag generation algorithm is run by the data owner. It inputs the system public parameter $params$, the data owner's secret key $sk$, and the message $M$, and outputs the aggregated tag $T$ for the message.

${\sf Challenge}$ $(params, I, pk_A/(tk_{A\rightarrow B}, pk_B))\rightarrow (chal, s)$: The challenge algorithm is run by the third party auditor. It inputs the system public parameter $params$, a set of indexes $I$ selected for data auditing, and can be further divided into the following two types.

● For auditing data before transferring, the challenge algorithm also takes the original data owner's public key $pk_A$ as input;

● For auditing data after transferring, the challenge algorithm also takes the transfer token $tk_{A\rightarrow B}$ provided by the new owner and its public key $pk_B$ as input.

Then, the challenge algorithm outputs the challenge $chal$ and a secret value $s$, which will be used in later verification.

${\sf Respond}$ $(params, chal, \{m_i\}, \{T_j\})\rightarrow res$: The response algorithm is run by the cloud server. It inputs the system public parameter $params$, challenge $chal$, and the message block set $\{m_i\}$ with aggregated tag set $\{T_j\}$ (the tag $t_i$ for message block $m_i$ is aggregated into $T_j$) that is stored in the locations that correspond to the indexes indicated in the challenge, and outputs the response $res$.

${\sf Verify}$ $(params, chal, res, s)\rightarrow 1/0$: The verification algorithm is run by the third-party auditor. It inputs the system public parameter $params$, challenge $chal$, response $res$, and the secret value $s$ generated during the challenge phase, and outputs the verification result $1/0$. Specifically, if the response passes the verification, it outputs $1$; otherwise, it outputs $0$.

Correctness. The correctness requirement of a transferable data auditing scheme is defined as follows. If the auditing request is launched by the original data owner before transferring, it is required that, for any public and secret key pair $(pk, sk)$ generated by the key generation algorithm ${\sf KeyGen}$, any message $M$ and the corresponding tag $T$ generated by the tag generation algorithm ${\sf TagGen}$ with the secret key $sk$, any challenge $chal$ generated by the challenge algorithm ${\sf Challenge}$ with the public key $pk$, and any response $res$ generated by the response algorithm ${\sf Respond}$ with valid message blocks and aggregated tags, the verification is valid, i.e.,

If the auditing request is launched by the transfer target user after transferring, it is required that, for any public and secret key pairs $(pk_A, sk_A), (pk_B, sk_B)$ generated by the key generation algorithm ${\sf KeyGen}$, any transfer token $tk_{A\rightarrow B}$ generated by the transfer token generation algorithm ${\sf TokenGen}$, any message $M$ and the corresponding tag $T$ generated by the tag generation algorithm ${\sf TagGen}$ with the secret key $sk_A$, any challenge $chal$ generated by the challenge algorithm ${\sf Challenge}$ with the transfer token $tk_{A\rightarrow B}$ and public key $pk_B$, and any response $res$ generated by the response algorithm ${\sf Respond}$ with valid message blocks and aggregated tag, the verification is valid, i.e.,

3.2.   Threat model

The threat model of a cloud auditing scheme with static data transfer is defined through the following game.

Setup. The challenger runs the ${\sf Setup}$ and ${\sf KeyGen}$ algorithms of the scheme to get the public parameter $params$ and two key pairs of data owners $(pk_A, sk_A), (pk_B, sk_B)$. Then, it runs the ${\sf TokenGen}$ algorithm to get a transfer token $tk_{A\rightarrow B}$. Next, it returns $(params, pk_A, pk_B)$ to the adversary.

Tag query. The adversary can adaptively query tags for a message $M$, and the challenger runs the ${\sf TagGen}$ algorithm with the secret key $sk_A$ to get the tag $T$ and returns $T$ to the adversary.

Verification query. This query involves the interactions between the challenger and the adversary. The adversary can adaptively make challenge requests, including the challenges before data transfer and after data transfer. The challenger runs the ${\sf Challenge}$ algorithm to get the challenge $chal$ and secret $s$ will be used later for verification. Then, it gives the challenge $chal$ to the adversary. Next, the adversary sends the response $res$ to the challenger. Finally, the challenger runs the ${\sf Verify}$ algorithm to get the result and returns it to the adversary.

Challenge. The adversary indicates a challenge request for an auditing before or after data transfer. The challenger runs the ${\sf Challenge}$ algorithm according to the adversary's choice to get the challenge $chal^*$ and secret value $s^*$ used for later verification. Then, it returns $chal^*$ to the adversary.

Forge. Finally, the adversary outputs a response $res^*$.

The adversary wins the game if the following conditions hold.

$1)$ The response is valid, i.e., ${\sf Verify}(params, chal^*, res^*, s^*) = 1$;

$2)$ The adversary never queries the tag for the message stored in the index used to generate the challenge $chal^*$.

We say adversary $\mathcal{A}$ has advantage $\epsilon$ in breaking the scheme if

Definition 3. We say the cloud auditing scheme with static data transfer is $(t, \epsilon)$-secure, if for any P.P.T. adversary that runs within time $t$, its advantage in winning the above game is at most $\epsilon$.

4.   Concrete construction

4.1.   Scheme description

In this section, we present the concrete construction of the cloud auditing scheme with static data transfer. The details of the seven algorithms are depicted as follows.

$\textsf{Setup} (1^\kappa, n)$. On input the security parameter $1^\kappa$ and another parameter $n$, the setup algorithm first generates pairing groups $\mathbb{PG} = (\mathbb{G}_1, \mathbb{G}_2, \mathbb{G}_T, p, g_1, h_2, e)$ with an admissible pairing $e: \mathbb{G}_1\times \mathbb{G}_2\rightarrow \mathbb{G}_T$ and generators $g_1\in \mathbb{G}_1, h_2\in \mathbb{G}_2$. Then, it selects cryptographic hash functions $H:\{0, 1\}^*\rightarrow \mathbb{G}_1, H_2:\{0, 1\}^*\rightarrow \mathbb{Z}_p$ and publishes the system public parameter $params = (\mathbb{PG}, H, H_2, n)$.

$\textsf{KeyGen} (params)$. On input the system public parameter $params$, the key generation algorithm selects a random $a\in \mathbb{Z}_p$ and computes $(h_2^a, h_2^{a^2}, \dots, h_2^{a^n}, h_2^{a^{n+1}}, \dots, h_2^{a^{2n}})$. Then, it outputs a pair of public key and secret key

$\textsf{TokenGen} (params, sk_A, pk_B)$. On input the system public parameter $params$, the original data owner's secret key $sk_A = a$, and the new owner's public key $pk_B = (h_2^b, h_2^{b^2}, \dots, h_2^{b^n}, h_2^{b^{n+1}}, \dots, h_2^{b^{2n}})$, the transfer token generation algorithm computes

Then, it outputs the transfer token $tk_{A\rightarrow B} = \left(h_2^{\frac{b^{n+1}}{a}}, \dots, h_2^{\frac{b^{n+1}}{a^n}}, h_2^{ab^{n+1}}, \dots, h_2^{a^nb^{n+1}}\right)$.

$\textsf{TagGen} (params, sk, M)$. On input the system public parameter $params$, secret key $sk$, and message $M$, the tag generation algorithm parses message $M$ into elements in $\mathbb{Z}_p$, i.e., $M = (m_1, m_2, \dots), m_i\in \mathbb{Z}_p$. Suppose the file name of the message is $f$, it first computes $i = j\cdot n+k$, for $k\in [1, n]$; then computes the tag $t_i$ for $m_i$ as

Next, it aggregates every $n$ tags into one aggregated tag as

The final tag $T$ for message $M$ consists of the aggregated tags $T = \{T_1, \dots, T_{j+1}\}$.

$\textsf{Challenge} (params, I, pk_A/(tk_{A\rightarrow B}, pk_B))$. On input the system public parameter $params$, a randomly selected set of indexes $I$, the challenge algorithm picks a random $r_i\in \mathbb{Z}_p$ for each index $i$ from set $I$ and then proceeds as one of the following two branches.

● For auditing data before transferring, it additionally inputs the original data owner's public key $pk_A = (h_2^a, h_2^{a^2}, \dots, h_2^{a^n}, h_2^{a^{n+1}}, \dots, h_2^{a^{2n}})$. Next, it picks a random $c\in \mathbb{Z}_p$ and computes

Please note the item $h_2^{ca^{n+1}}$ serves as the secret value $s$ that will be used in later verification and is not included in the above tuple.

● For auditing data after transferring, it additionally inputs the transfer key

and the transfer target user's public key $pk_B = (h_2^b, h_2^{b^2}, \dots, h_2^{b^n}, h_2^{b^{n+1}}, \dots, h_2^{b^{2n}})$. Next, it picks a random $c\in \mathbb{Z}_p$ and computes

Please note that the item $h_2^{cb^{n+1}}$ (computed from $h_2^{b^{n+1}}\in pk_B$ and $c$) serves as the secret value $s$ that will be used in later verification and is not included in the above tuple.

It outputs the challenge $chal$ and secret value $s$.

$\textsf{Respond} (params, chal, \{m_i\}, \{T_j\})$. On input, the system public parameter is $params$ and challenge is $chal$, and the response algorithm parses the challenge $chal$ to get the index set $I$ and for each $i\in I$ computes $i = j\cdot n+k$, where $k\in [1, n]$. Then, it finds the message blocks ${m_i}$ and the aggregated tags $\{T_{j+1}\}$ (contains $t_i$). Suppose the file name is $f$; then, it proceeds as one of the following two branches.

● For a challenge on the data before transferring, the challenge

Compute the evolution tag $e_i$ from the aggregated tag $T_{j+1} = \prod\limits_{l = jn+1}^{(j+1)n} t_l$ as

● For a challenge on the data after transferring, the challenge

Compute the evolution tag $e_i$ from the aggregated tag $T_{j+1} = \prod\limits_{l = jn+1}^{(j+1)n} t_l$ as

Next, it computes $\mu = \sum\limits_{(i, r_i)\in chal} m_i \cdot r_i\ \text{mod }p, \sigma = \prod\limits_{(i, r_i)\in chal} e_i^{r_i}$ and outputs the response as $res = (\mu, \sigma)$.

$\textsf{Verify} (params, chal, res, s)$. On input, the system public parameter $params$, challenge $chal$, response $res$, and the secret value $s$, the verification algorithm parses $res = (\mu, \sigma)$ and checks whether the following equation holds:

If the above equation holds, it outputs $1$; otherwise, it outputs $0$.

Correctness. For simplicity, we consider one index $i$ in the challenge and the general case that involves arbitrary number of indexes can be easily extended. For an auditing request before data transfer, the challenge is

and the secret is $s = h_2^{ca^{n+1}}$. For message $m_i$ and valid aggregated tag $T_{j+1}$ stored at index $i$ that includes tag $t_i$, the evolution tag $e_i = e(H(f||i)\cdot g_1^{m_i}, h_2^{ca^{n+1}})$ is recovered during the response phase. Then, the response is computed as $\mu = m_i\cdot r_i\text{ mod }p, \sigma = e_i^{r_i}$ and $res = (\mu, \sigma)$. Given the response and secret $s$, it is easy to see

For an auditing request after data transfer, the challenge is

and the secret is $s = h_2^{cb^{n+1}}$. Similarly, for message $m_i$ and valid aggregated tag $T_{j+1}$, evolution tag $e_i = e(H(f||i)\cdot g_1^{m_i}, h_2^{cb^{n+1}})$ is recovered during the response phase. Response $\mu = m_i\cdot r_i\text{ mod }p, \sigma = e_i^{r_i}$ are computed and $res = (\mu, \sigma)$. It is easy to see that

Therefore, in both cases, we have $\Pr[{\sf Verify}(params, chal, res, s) = 1] = 1$. The correctness of the scheme holds.

4.2.   Security analysis

In this section, we present the security analysis of our proposed scheme construction. As discussed, our scheme is built by combining the basic scheme with the evolution tag technique ^[43]. Next, we show that its security can also be reduced to the scheme in ^[43] and hence is based on the $n$-GDHE assumption.

Theorem 1. If the cloud auditing scheme in ^[43] is $(t, \epsilon)$-secure under the defined threat model, then our scheme is $(t', \epsilon')$-secure under the threat model defined in Section 3.2, where $t'\approx t$ and $\epsilon'\approx \epsilon$.

Please refer to the appendix for the details of proof.

4.3.   Efficiency analyses

In this section, we give the performance comparison of our proposed scheme with related research in terms of computation and transmission costs. In addition to the underlying evolution tag technique in ^[43] that acts as the baseline, we also present comparisons with the scheme by Yan and Gui ^[45] of an identity-based cloud auditing, the scheme by Wang et al. ^[46] of a revocable cloud auditing, that are both designed for data sharing scenario, and the scheme by Shen et al. ^[5] that is proposed for data transfer purposes.

As for the computation costs, the detailed comparison in terms of tag generation, response, verification, and data transfer phases are presented in Table 3 as follows: From the table, we can see that there is not too much computational overhead in tag generation and verification phases of our scheme compared with other schemes that do not support data transfer or tag aggregation. Our scheme and ^[43] have a more complicated response phase since there is the need of computing the evolution tag. Nevertheless, these computations are conducted on the server side and do not involve any system user. Our scheme has an efficient transfer process, and $O(1)$ means it requires only simple and constant number operations on the server side. On the other hand, the schemes in ^[46] and ^[5] require linear number operations with respect to the size of the data to be transferred.

As for transmission costs, the detailed comparison in terms of data upload, challenge, response, and data transfer phases are presented in Table 4 as follows: From the table, we can see that the storage efficiency and cost during data upload phase of our scheme is the same as ^[43], which is more efficient compared with other schemes. The challenge phase requires more bandwidth since the public key and token consist of multiple elements, which is linear with parameter $n$. This can also be further improved using the same random $c\in \mathbb{Z}_p$ during the challenge phase and denoting the tuple $(h_2^{ca}, h_2^{ca^2}, \dots, h_2^{ca^{2n}})$ as $tpk$ used by TPA for every challenge. For data transfer, only the token needs to be delivered and is done once and for all. This means the cost is independent of the size of data or the time involved in the transfer.

Next, we give the simulation results of our scheme together with the aforementioned schemes. The implementation details are as follows: The experiment is conducted on a laptop with Intel(R) Core(TM) i7-9750H CPU 2.60 GHz and a 16.0 GB RAM. All the algorithms are implemented with Java language with IDEA2024 compiler and 2.0.0 JPBC library. We use the symmetric bilinear pairing $e:\mathbb{G}_1 \times \mathbb{G}_1 \rightarrow \mathbb{G}_2$ with 80-bit security, which is known as the Type A curves in JPBC library. The curve is defined in equation $y^2 = x^3+x\ (mod \: p)$, where $p$ is a prime of $512$ bits, and the order of the group is of $rBits$ = 160 bits, with the embedding degree $k$ = 2. We run each algorithm 50 times to get the average running time.

To show the effectiveness of the TagGen, Respond, and Verify algorithms, the simulation results of our scheme, ^[45], and ^[43] are presented, and their time costs are shown in Figures 6–8, respectively. The number of data blocks is incremented from 50 to 500. In the tag generation phase, we assume the message is composed of exactly the number of data blocks; in response and verification phases, we also set the number of challenged blocks from 50 to 500. The costs of tag generation, response, and verification increase linearly with the number of data blocks. The cost of scheme ^[45] is slightly higher since the scheme is in the shared data scenario. From Figures 6–8, we can see that our scheme and ^[43] behaves almost the same in terms of the three phases, which means that there is very little extra computation burden that gets involved to achieve static data transfer.

To demonstrate the advantage of efficient data transfer in the static way, we give the simulation result of data transfer among our scheme, ^[46], and ^[5]. The number of data blocks is incremented from 500 to 5000. From Figure 9, we can see that the costs of scheme ^[46] and ^[5] increase linearly with the number of data blocks while it remains constant, and almost no computation operation is needed in our scheme. Due to static transfer property, efficiency is guaranteed.

5.   Conclusions

In this paper, we focused on how to achieve cloud auditing that supports efficient data transfer. We first introduced the notion of static transfer and defined the threat model. Since the data and tags remain unchanged during the transfer process, which is referred to as "static'', the computation and transmission efficiency is guaranteed. A basic scheme was proposed to demonstrate the core technique. Furthermore, to pursue storage efficiency, we combined the evolution tag technique, which is also built upon the BLS-type. By elaborately designing the key, token, and challenge structure, we presented our complete cloud auditing scheme with static data transfer. According to the experimental results, the key, tag, challenge, and response phases remained the same, without computation or transmission efficiency. Moreover, the storage efficiency can also be improved since the tags are aggregated.

Nevertheless, there are limitations and possible improvements for the scheme. First, the parameter that indicates how many tags can be aggregated in evolution tag technique is settled when the system is setup. If the parameter can be adaptively updated, then the tradeoff between storage efficiency and computation costs can be more flexible. Second, when the data is transferred to the new owner, the new owner needs to store the transfer token for later use. This modifies the scheme from stateless to stateful. Although the size of the token is much smaller than the data or lower than the transmission cost, this may bring a passive influence to practical applications. Third, when the transfer is complete, the original owner may be able to grant a transfer token with its secret key. This situation can be avoided by introducing supervision mechanisms and taking responsibility for token abuse. Overall, the aforementioned extensions of the current construction are future research directions.

Use of AI tools declaration

The authors declare they have not used Artificial Intelligence (AI) tools in the creation of this article.

Acknowledgments

This paper is supported by National Natural Science Foundation of China (Nos. 62372103 and 62002058), Natural Science Foundation of Jiangsu Province (No. BK20200391), and Fundamental Research Funds for the Central Universities (No. 2242021R40011).

Conflict of interest

The authors declare there is no conflict of interest.

Appendix (Proof of Theorem 1)

Proof. Suppose there exists an algorithm $\mathcal{A}$ that has advantage $\epsilon'$ in breaking our scheme. We show how to construct an efficient algorithm $\mathcal{B}$ that has advantage $\epsilon\approx \epsilon'$ in breaking the scheme in ^[43]. The algorithm $\mathcal{B}$ interacts with algorithm $\mathcal{A}$ as follows.

Setup phase. Upon receiving the public parameter $params$ and public key $pk$ of the scheme in ^[43], where $pk = (h_2^a, h_2^{a^2}, \dots, h_2^{a^n}, h_2^{a^{n+1}}, \dots, h_2^{a^{2n}})$, $\mathcal{B}$ sets $pk_A = pk$, picks a random $t\in \mathbb{Z}_p$, and sets $pk_B = ((h_2^a)^t, \dots, (h_2^{a^n})^{t^n}, \dots, (h_2^{a^{2n}})^{t^{2n}})$. Then, $\mathcal{B}$ returns $(params, pk_A, pk_B)$ to algorithm $\mathcal{A}$. Please note that the secret key $sk_B = b$ for data owner $B$ is implicitly set as $b = a\cdot t$, which is also not known to $\mathcal{B}$.

Tag query phase. When $\mathcal{A}$ submits a tag query on a message block $m\in \mathbb{Z}_p$, $\mathcal{B}$ transmits the tag query to the challenger $\mathcal{C}$ and receives the tag $t$. Then, $\mathcal{B}$ returns $t$ to $\mathcal{A}$. It is easy to see that $\mathcal{B}$ can always correctly answer tag queries without abort.

Verification query phase. When $\mathcal{A}$ submits a challenge request for verification query,

● If the challenge is before data transfer, $\mathcal{B}$ transmits the request to $\mathcal{C}$ and receives the challenge $chal$. Then, it gives $chal$ to $\mathcal{A}$ and receives the response $res$. Next, it transmits $res$ to $\mathcal{C}$ and receives the result. Finally, $\mathcal{B}$ returns the result to $\mathcal{A}$. $\mathcal{B}$ can always correctly answer verification queries before data transfer.

● If the challenge is after data transfer, $\mathcal{B}$ transmits the request to $\mathcal{C}$ and receives the challenge $chal$, where $chal = (i, r_i, h_2^{ca}, h_2^{ca^2}, \dots, h_2^{ca^n}, h_2^{ca^{n+2}}, \dots, h_2^{ca^{2n}})$. Then, $\mathcal{B}$ computes

and it is easy to see that all the components required in the challenge can be reformulated as

Next, $\mathcal{B}$ sets $chal_B = \left(\begin{matrix}i, r_i, h_2^{ca\cdot t^{n+1}}, \dots, h_2^{ca^n\cdot t^{n+1}}, h_2^{ca^{n+2}\cdot t^{n+1}}, \dots, h_2^{ca^{2n}\cdot t^{n+1}}\end{matrix}\right)$ and returns $chal_B$ to $\mathcal{A}$. On receiving the response $res$ from $\mathcal{A}$, which contain the item $e_i = e(H(f||i)\cdot g_1^{m_i}, h_2^{cb^{n+1}}) = e(H(f||i)\cdot g_1^{m_i}, h_2^{ca^{n+1}\cdot t^{n+1}})$, $\mathcal{B}$ first computes $e_i^{1/t^{n+1}} = e(H(f||i)\cdot g_1^{m_i}, h_2^{ca^{n+1}})$ and then transmits the updated item $e_i^{1/t^{n+1}}$ to $\mathcal{C}$. Finally, $\mathcal{B}$ receives the result from $\mathcal{C}$ and returns the result to $\mathcal{A}$. The validness of the results to both $\mathcal{B}$ and $\mathcal{A}$ are the same and hence $\mathcal{B}$ can always correctly answer verification queries after data transfer.

Challenge phase. $\mathcal{A}$ submits the challenge request on an index $i^*$ that it never makes a tag query before and identifies the challenge is before or after data transfer.

● If the challenge is before data transfer, $\mathcal{B}$ transmits the request to $\mathcal{C}$ and receives the challenge $chal_A$. Then, $\mathcal{B}$ sets the challenge $chal^*$ as $chal^* = chal_A$;

● If the challenge is after data transfer, $\mathcal{B}$ transmits the request to $\mathcal{C}$ and receives the challenge $chal_A$. Similar to the above phase, $\mathcal{B}$ parses $chal_A$ as $(i^*, r_i^*, h_2^{ca}, h_2^{ca^2}, \dots, h_2^{ca^n}, h_2^{ca^{n+2}}, \dots, h_2^{ca^{2n}})$, computes and sets $chal^* = \left(i^*, r_i^*, h_2^{ca^n\cdot t^{n+1}}, \dots, h_2^{ca\cdot t^{n+1}}, h_2^{ca^{n+2}\cdot t^{n+1}}, \dots, h_2^{ca^{2n}\cdot t^{n+1}}\right)$.

Then, it returns the challenge $chal^*$ to $\mathcal{A}$.

Forge phase. $\mathcal{A}$ outputs a valid response $res^* = (\mu^*, \sigma^*)$.

● If $\mathcal{A}$ chooses the challenge before data transfer, then $res^*$ is also valid for the challenge $chal_A$ received from challenger $\mathcal{C}$. $\mathcal{B}$ transmits $res^*$ to $\mathcal{C}$;

● If $\mathcal{A}$ chooses the challenge after data transfer, then from the analysis above, we have

Next, $\mathcal{B}$ computes $(\sigma^*)^{1/t^{n+1}} = e(H(f||i^*)\cdot g_1^{m_{i^*}}, h_2^{ca^{n+1}})$, updates the response as $res^* = \left(\mu^*, (\sigma^*)^{1/t^{n+1}}\right)$ with the above item, and transmits $res^*$ to $\mathcal{C}$.

Since $res^*$ outputted by $\mathcal{A}$ is valid, the updated response submitted by $\mathcal{B}$ is also valid and hence $\mathcal{B}$ also wins the game against the challenger of scheme in ^[43].

During the above phases, $\mathcal{B}$ can answer the queries and there is no abort. Therefore, we construct an algorithm that runs within polynomial time $t'$ and has an advantage $\epsilon'$, which is approximately to $\epsilon$. This completes the proof of Theorem 1. □