What If Keys Are Leaked? towards Practical and Secure Re-Encryption in Deduplication-Based Cloud Storage

Abstract

By only storing a unique copy of duplicate data possessed by different data owners, deduplication can significantly reduce storage cost, and hence is used broadly in public clouds. When combining with confidentiality, deduplication will become problematic as encryption performed by different data owners may differentiate identical data which may then become not deduplicable. The Message-Locked Encryption ($\mathsf{MLE}$) is thus utilized to derive the same encryption key for the identical data, by which the encrypted data are still deduplicable after being encrypted by different data owners. As keys may be leaked over time, re-encrypting outsourced data is of paramount importance to ensure continuous confidentiality, which, however, has not been well addressed in the literature. In this paper, we design SEDER, a SEcure client-side Deduplication system enabling Efficient Re-encryption for cloud storage by (1) leveraging all-or-nothing transform ($\mathsf{AONT}$), (2) designing a new delegated re-encryption ($\mathsf{DRE}$), and (3) proposing a new proof of ownership scheme for encrypted cloud data ($\mathsf{PoWC}$). Security analysis and experimental evaluation validate security and efficiency of SEDER, respectively.

1. Introduction

Cloud storage services are widely deployed nowadays. Popular services include Amazon S3 [1], Apple iCloud [2], and Microsoft Azure [3]. By using cloud services, data owners pay for storage they use, eliminating expensive costs of maintaining dedicated infrastructures.

As more and more users turn to public clouds for storage, the amount of data stored in clouds grows rapidly. Conventionally, the clouds simply store what have been sent by the data owners. This unfortunately will lead to a significant waste of storage space, as different data owners may upload identical data. A remediation is to perform deduplication, in which clouds only store a unique copy of duplicate data from different data owners to reduce unnecessary waste of storage space. For example, research from Microsoft [4] showed that deduplication can achieve 50% and 90–95% storage savings in the standard file systems and backup systems, respectively. Almost all the existing popular file hosting services like Dropbox [5] and Box [6] perform data deduplication.

There are two popular data deduplication mechanisms: server-side deduplication and client-side deduplication. Their main differences are: in server-side deduplication, servers perform deduplication on the outsourced data, transparently to the clients (data owners); in client-side deduplication, the servers and the clients cooperate to perform deduplication. Compared to the server-side deduplication, the client-side deduplication has a significant benefit that the clients do not need to upload those data that have been stored at servers, significantly reducing bandwidth consumption. Therefore, the client-side deduplication is used more broadly in public file hosting services [5,6].

As public cloud providers are usually untrusted [7], data owners hesitate to outsource sensitive data to them due to various concerns. First, data owners fear ownership loss of critical assets. This is because, once the attacker can obtain a data copy, it can simply claim ownership of the data and it is hard to differentiate who originally owns the data. Second, data owners worry about unauthorized access of their sensitive data. Since the data are now hosted by the cloud providers, no guarantees can be provided to data owners that their sensitive information is under strict control and will not be abused. A common solution which can mitigate the aforementioned concerns is to encrypt data using a secret key before outsourcing them. In this way, the provider only “owns” the meaningless encrypted data rather than the original sensitive data. In addition, without having access to the key, unauthorized users can only have access to the encrypted data.

Encryption, however, creates a severe obstacle for deduplication, as identical plaintext may be encrypted into different ciphertext by different data owners who usually use different keys. To resolve this issue, a cryptographic primitive called Message-Locked Encryption ($\mathsf{MLE}$) [8,9,10,11,12] was proposed, which derives encryption keys based on the plaintext being encrypted. Using $\mathsf{MLE}$, different data owners can generate identical encryption keys for the same content, leading to deduplicable (One implied assumption for $\mathsf{MLE}$ is that the same encryption algorithm will be used by different data owners.) ciphertexts. In practice, encryption keys may be leaked [13,14] and those keys should not be used any more, or data may be deleted by some users and ownership of those users on the data should be revoked [15]. Under such circumstance, to ensure continuous confidentiality of sensitive data, re-encrypting the data using a new key is necessary. Li et al. proposed REED [15] to address the re-encryption problem for deduplication-based encrypted storage systems, which is specifically designed for the server-side deduplication. On the contrary, our design in this work specifically targets the client-side deduplication.

Compared to the design for the server-side deduplication (e.g., REED [15]), ours faces various new challenges especially for the encrypted data. In the server-side deduplication, the client simply uploads the encrypted file to the server and does not get involved in the deduplication process; in the client-side deduplication, however, upon uploading a new file, the client needs to first check whether the file has been stored in the server and, if the file has been stored, the server needs to verify whether the client actually owns the file before adding it to the owner list of the file. This raises a few issues especially for the encrypted data: (1) The server stores an encrypted version of the file, but the client stores a plaintext version of the file. It is non-trivial for the client to efficiently check whether there are identical files stored in both parties. (2) To allow the server to verify whether the client owns the file, the conventional proof of ownership (PoW [16]) protocol requires both the server and the client possessing the same file format (e.g., both are plaintext). It clearly cannot be applied here since the server and the client do not possess the same file format. In addition, since the outsourced data are encrypted and the server does not have access to the encryption key, in both the server-side and the client-side deduplication, the re-encryption process needs to involve the client or a trusted third party who manages clients’ keys. However, the existing designs for the client-side deduplication [17,18] require re-encrypting the entire file whenever the re-encryption happens. The more efficient design for the server-side deduplication [15] simply requires the client to conduct the re-encryption process, which may impose a significant burden on the client.

This paper addresses the aforementioned issues by proposing the first SEcure client-side Deduplication system enabling Efficient Re-Encryption (SERER) for cloud storage. The key insights are threefold: First, we design a novel technique which can allow efficiently detecting duplicate files between two parties even if the file is in different file formats (i.e., a plaintext file format and an encrypted file format). Second, we adapt the traditional PoW scheme, such that it can work correctly even when the server and the client possess different file formats, i.e., the new PoW design can allow the server, which possesses the encrypted version of the file, to efficiently verify whether the client possesses the plaintext of the file. Third, by leveraging all-or-nothing transform and delegated re-encryption, we enable secure re-encryption without imposing a heavy load on the client side. Specifically, by introducing all-or-nothing transform, we make it possible to re-encrypt a file by only re-encrypting a small portion of it; in addition, by adapting proxy re-encryption, we delegate the re-encryption to the cloud server, which possesses a large amount of computational power. Compared to our conference version [19], major differences of this article are: (1) We propose a new approach which can efficiently detect duplicate files between the client and the server even if each stores the file in a different format, i.e., the client stores the plaintext file while the server stores the encrypted file. On the contrary, in the conference version, the client needs to first encrypt the entire plaintext file which incurs a large overhead. (2) We simplify the design of delegated re-encryption, incurring less overhead compared to the conference version. (3) We design $\mathsf{PoWC}$, a new PoW scheme that can work correctly even if the server and the client possess different file formats. On the contrary, the conference version directly relies on the original PoW protocol and can only ensure that the prover (i.e., the client) possesses an encrypted version of the original file, rather than the actual original file. (4) We provide a more thorough and formal security analysis. (5) We implement the new designs and re-evaluate the performance of SEDER.

• Contributions. We summarize our contributions as follows:
  • We initiate research of the re-encryption problem for secure client-side deduplication in public clouds. The resulted design, SEDER, is a SEcure client-side Deduplication system allowing Efficient Re-encryption.
  • We have designed a new delegated re-encryption ($\mathsf{DRE}$) scheme and a novel proof of ownership (PoW) scheme for ciphertext ($\mathsf{PoWC}$). We also propose a new approach that can securely and efficiently detect duplicate files between the client and the server even though they store the files in a different format. The re-encryption for secure client-side deduplication is enabled by smartly leveraging the aforementioned schemes as well as all-or-nothing transform ($\mathsf{AONT}$).
  • We theoretically analyze security of SEDER. We also experimentally evaluate its performance.

2. Backgroud

2.1. Deduplication and Proofs of Ownership (PoWs)

Deduplication is a widely used technique in the cloud environment [4], aiming at removing cross-user duplicates. Note that the deduplication does not contradict with the known durability technique, which replicates data redundantly [20,21,22,23] such that data can be always recoverable upon being corrupted. This is because the redundant data created for durability purposes usually belong to a single user, and the deduplication technique removes redundant data cross users, which were unknown by users and have not been used for durability purposes. Based on granularity of duplicates, deduplication can be categorized as file-level [9] (i.e., duplicates in files) and block-level [24] (i.e., duplicates in blocks/chunks) deduplication. Another categorization of deduplication is based on where deduplication is performed. In a server-side deduplication, all files are uploaded to a cloud server, and the cloud server performs deduplication transparently to clients. In a client-side deduplication, the client first checks whether the file has been stored in the server by uploading a checksum of the file. If the file already exists in the server side, there is no need to upload the file (bandwidth saving), and the server simply adds the client as the owner of this file. In this paper, we focus on client-side deduplication, which is used broadly in practice (e.g., Dropbox [5], Box [6]). In addition, we use the file-level deduplication for simplicity, but the idea could be applicable to the block-level deduplication.

One attack faced by the client-side deduplication is that an adversary that obtains the file checksum can simply claim ownership of this file. Proofs of Ownership (PoWs) have been explored to mitigate this attack. A typical PoW protocol based on Merkle-tree was proposed by Halevi et al. [16], in which the prover answers with the sibling-path for each leaf node being challenged and the verifier checks: (1) whether every sibling-path is valid or not based on the stored root; and (2) whether each leaf node being challenged is a correct hash value of the corresponding file block.

2.2. Message-Locked Encryption (MLE)

$\mathsf{MLE}$ [8] is a scheme designed to derive encryption keys from messages being encrypted. In $\mathsf{MLE}$, different data owners are able to generate the same key for identical data. Existing $\mathsf{MLE}$ schemes include CE [9], DupLESS [10], Duan Scheme [11], and the LAP scheme [12]. A secure $\mathsf{MLE}$ scheme ensures that only the data owners who possess the exact same content can obtain the corresponding encryption key.

2.3. All-Or-Nothing Transform (AONT)

$\mathsf{AONT}$ [25] is an unkeyed, invertible, and randomized transformation. No one can succeed in performing the inverse transformation without knowing the entire output of the $\mathsf{AONT}$. Specifically, given message m of l-blocks, $m=m_1\left|\right|\dots \left|\right|m_l$ where $\left|\right|$ denotes block concatenation, $\mathsf{AONT}$ transforms m into message $m^{\prime }$ of $l^{\prime }$-blocks, $m^{\prime }=m_1^{\prime }\left|\right|\dots \left|\right|m_{l^{\prime }}^{\prime }$, where $l^{\prime }\ge l$. The transformation satisfies the following properties:

• Given m, $m^{\prime }\leftarrow \mathsf{AONT}\left(m\right)$ can be computed efficiently. That is, the complexity of $\mathsf{AONT}\left(m\right)$ is polynomial to the length of m.
• Given $m^{\prime }$, $m\leftarrow {\mathsf{AONT}}^{-1}\left(m^{\prime }\right)$ can be computed efficiently.
• Without knowing the entire $m^{\prime }$ (i.e., if one block is missing), the probability of recovering m is negligibly small.

2.4. Discrete Logarithm Problem (DLP)

We have a finite cyclic group G of order q, and the corresponding generator is denoted as g. For a given element $y\in \mathbb{G}$, the discrete logarithm problem is to find an integer $0\le x<q-1$ such that $g^x=y$. The discrete logarithm problem is hard, i.e., there is no known algorithm that can compute x in polynomial time [26].

3. Model and Assumptions

• System model. We consider two entities, cloud server ($\mathsf{CS}$) and data owner ($\mathsf{O}$). The cloud server offers storage services and wants to perform client-side deduplication to reduce storage and bandwidth cost. The data owners outsource their file to the cloud server. To maintain data confidentiality of their outsourced file, they will encrypt the file before outsourcing them. Note that, when the data owner tries to upload a file that has been stored in the cloud server, $\mathsf{CS}$ will append this data owner to the owner list of the corresponding file without requiring uploading the entire file again.
• Adversarial model. All the data owners are assumed to be fully trusted. In addition, it is an authentic data owner that uploads the original file initially. However, the cloud server $\mathsf{CS}$ is honest-but-curious [7,27]. $\mathsf{CS}$ will honestly store the encrypted files uploaded by the data owner, perform data deduplication, and respond to requests from data owners. Moreover, $\mathsf{CS}$ will not disclose data to anyone who fails to prove ownership of the data. However, it is curious and attempts to infer sensitive information about the encrypted file. We assume there is a malicious entity ($\mathsf{ME}$) which attempts to recover sensitive data in the file using key materials obtained, or to pass the ownership verification during the client-side deduplication without really possessing the file.

The $\mathsf{ME}$ cannot be a special attacker, which is a revoked data owner who still keeps the original file, but it can be an attacker, which is a revoked data owner who has completely removed the original file.

• Assumptions. We assume that $\mathsf{MLE}$ is secure (The $\mathsf{MLE}$ has been well investigated in the literature. For instance, DupLESS [10], Duan Scheme [11], and LAP scheme [12] are resistant to offline brute-force attack.). The PKI can function securely and each entity has an asymmetric key pair, in which the private key is well protected. All the communication channels are protected by SSL/TLS, so that any eavesdroppers cannot infer information about messages being exchanged. There is no collusion between $\mathsf{CS}$ and $\mathsf{ME}$ since neither of them can obtain any advantages through collusion.

4. SEDER

In this section, we introduce SEDER, a SEcure client-side Deduplication system enabling Efficient Re-encryption for cloud storage. We first design two new building blocks (Section 4.1), a delegated re-encryption scheme ($\mathsf{DRE}$) which allows delegating re-encryption to an untrusted third party and, a new PoW scheme which can allow a verifier (i.e., the cloud server) to check ownership of the original file by only having access to the ciphertext of the file. Based on the newly designed building blocks, we present the detailed design of SEDER (Section 4.2 and Section 4.3).

4.1. Building Blocks

4.1.1. Delegated Re-Encryption

Proxy re-encryption ($\mathsf{PRE}$) [28,29] allows a proxy to convert the ciphertext, which can only be decrypted by the delegator, into another ciphertext that can be decrypted by the delegatee, without leaking the plaintext to the proxy. Proxy re-encryption has several promising features, such as uni-direction, transparency to the proxy, and non-interaction between the delegator and the delegatee during the re-encryption process. However, the traditional proxy re-encryption [30] does not suit our scenario well because: first, we require that the re-encryption process can be repeated again and again, but traditional proxy re-encryption cannot support this requirement well. Second, in the traditional proxy re-encryption [30], the delegator and the delegatee do not share the secret key used for encryption, which is not true in our scenario. Our new design, Delegated Re-Encryption ($\mathsf{DRE}$), works as follows:

• $\mathsf{DRE}.\mathsf{SetUp}\left(1^{\gamma }\right)$: G is a multiplicative cyclic group of prime order p (p is an $\gamma$-bit prime number, which should be large enough). g is chosen from G at random and is known to all the parties.
• $\mathsf{DRE}.\mathsf{KeyGen}\left({\mathsf{O}}_i\right)$: Given data owner ${\mathsf{O}}_i$, this algorithm generates a secret key ${\mathsf{sk}}_i=k_i$, which is a number selected randomly from ${\mathbb{Z}}_p$.
• $\mathsf{DRE}.\mathsf{Enc}({\mathsf{sk}}_i,m)$: Message m is encrypted into $c_i=m{g}^{k_i}$, where m is from ${\mathbb{Z}}_p$.
• $\mathsf{DRE}.\mathsf{ReKeyGen}({\mathsf{sk}}_i,{\mathsf{sk}}_j)$: Given the data owner ${\mathsf{O}}_i$’s secret key ${\mathsf{sk}}_i$, the data owner ${\mathsf{O}}_j$ generates a re-encryption key based on its own secret key ${\mathsf{sk}}_j$ (which is a random number $k_j$, being generated by running $\mathsf{DRE}.\mathsf{KeyGen}\left({\mathsf{O}}_j\right)$) as well as ${\mathsf{sk}}_i$: $r{k}_{i\to j}=g^{k_j-k_i}$. This is specific for our design which is different from the traditional proxy re-encryption. In our design, all the data owners will share the secret keys, and hence data owner ${\mathsf{O}}_j$ knows ${\mathsf{O}}_i$’s secret key ${\mathsf{sk}}_i$. The purpose of the proxy here is to simply help perform the re-encryption, once the secret key ${\mathsf{sk}}_i$ is leaked. This purpose is slightly different from traditional proxy re-encryption, and we therefore use delegated re-encryption for differentiation.
• $\mathsf{DRE}.\mathsf{ReEnc}(r{k}_{i\to j},c_i)$: Given the re-encryption key $r{k}_{i\to j}$, the proxy can re-encrypt the ciphertext $c_i$ to $c_j$ by computing: $c_j=c_{i}r{k}_{i\to j}$.
• $\mathsf{DRE}.\mathsf{Dec}({\mathsf{sk}}_j,c_j)$: Given the ciphertext $c_j$, the data owner ${\mathsf{O}}_j$ decrypts it using ${\mathsf{sk}}_j=k_j$ by computing: $m=\frac{c_j}{g^{k_j}}$. This is because: $\frac{c_j}{g^{k_j}}=\frac{c_{i}r{k}_{i\to j}}{g^{k_j}}=\frac{m{g}^{k_i}{g}^{k_j-k_i}}{g^{k_j}}=m$.

4.1.2. A PoW Scheme for Ciphertexts ($\mathsf{PoWC}$)

The traditional PoW scheme [16] requires the verifier (e.g., the cloud server) to have access to the plaintext of the original file (Section 2.1). This requirement, however, cannot be satisfied in our scenario, in which the cloud server can only have access to the ciphertext of the outsourced file. We therefore need a new PoW protocol specifically for Ciphertext ($\mathsf{PoWC}$ for short), which can allow the verifier to check whether the prover (i.e., the client) really owns the original file by only having access to the corresponding ciphertext. You et al. [31] proposed a $\mathsf{PoWC}$ design by leveraging Intel SGX, which, however, requires the verifier to be equipped with the SGX security feature in the processor.

Our design of $\mathsf{PoWC}$ here aims to remove the assumption on the secure hardware. Motivated by DEW [32], we ask the initial data owner, who first uploads the ciphertext of the file, to compute and upload some auxiliary data which can be used later by the cloud server to verify ownership of the original file. Note that, for security, the auxiliary data should satisfy two properties: (1) They can be used by the cloud server to correctly verify the PoW proof, which is computed over the original file by the client. (2) The cloud server should not learn anything about the original file by utilizing the auxiliary data. For performance, the auxiliary data should consume significantly less storage space compared to the original data to avoid cancelling benefits of deduplication. Note that we are not able to compute the auxiliary data simply following the DEW [32], since their auxiliary data are specifically computed from the watermarked version of multimedia files. In our scenario, we do not have “watermarks”.

To construct the auxiliary data, we start from the PoR (Proofs of Retrievability [33]) tags which support private verifiability, which can be constructed as [33]: ${\sigma }_i=PR{F}_{\kappa }\left(i\right)+{\displaystyle \sum _{j=1}^s}{\alpha }_j{m}_{ij}$, where $i,j$ denote the index of each file block, and the index of each symbol (each symbol is from ${\mathbb{Z}}_q$, where q is a large prime) in the block, respectively, and “PRF” is a pseudo-random function with a secret key $\kappa$, and $\left\{{\alpha }_j\right|1\le j\le s\}$ is a set of s secret coefficients in ${\mathbb{Z}}_q$. Note that $\kappa$ and $\left\{{\alpha }_j\right|1\le j\le s\}$ need to be known by the verifier.

However, we observed that the privately verifiable PoR tags cannot be directly used for our purpose because: In traditional PoR scenarios, the client is the verifier and the cloud server is the prover; in our scenario, on the contrary, the cloud server is the verifier and the client is the prover, i.e., the cloud server needs to know $\kappa$ and $\left\{{\alpha }_j\right|1\le j\le s\}$ to perform verification. This could be problematic since, by knowing $\kappa$ and $\left\{{\alpha }_j\right|1\le j\le s\}$, the honest but curious cloud server (Section 3) may brute-force the original file content from the PoR tags due to the limited content space of a file.

Therefore, we need to allow the cloud server to verify the PoW proof without being able to brute-force the original file content. Our solution is: (1) We slightly change the construction of the tag to ${\sigma }_i=PR{F}_{\kappa }\left(i\right)+y{\displaystyle \sum _{j=1}^s}{\alpha }_j{m}_{ij}$, where y is a secret random number unknown to the cloud server. Specifically, y can be derived from a pseudo-random function with a secret key ${\kappa }_y$, and ${\kappa }_y$ can be generated by applying $\mathsf{MLE}$ on the original file. The server does not have the original file, and is not able to derive y. (2) We disclose $\left\{{\alpha }_j\right|1\le j\le s\}$ to the cloud server, but keep $\kappa$ secret from it. An issue remaining unsolved is, without knowing $\kappa$, how can the cloud server verify the PoW proof? To address this issue, we generate $\kappa$ by applying $\mathsf{MLE}$ on the original file. The server does not have the original file, and is not able to derive $\kappa$. When generating the PoW proof, the prover which actually possesses the original file will be able to compute $\kappa$, and then compute assisting information which assists the server to check the PoW proof. Note that $\left\{{\alpha }_j\right|1\le j\le s\}$ should be kept secret from the prover, and the assisting information should be able to be computed without knowing $\left\{{\alpha }_j\right|1\le j\le s\}$. In addition, to prevent the cloud server from learning the original file content from the PoW proof, the prover will mask each proof using randomness. The detailed design of our $\mathsf{PoWC}$ is elaborated as follows:

• $\mathsf{auxi}\leftarrow \mathsf{PoWC}.\mathsf{Init}\left(f\right):$ The data owner chooses a set of secret coefficients $\left\{{\alpha }_j\right|1\le j\le s\}$ from ${\mathbb{Z}}_q$. Given a file (f), the data owner pre-processes it and computes auxiliary data $\mathsf{auxi}$. By applying $\mathsf{MLE}$ over the file f, the data owner generates two keys $\kappa$ and ${\kappa }_y$. Using ${\kappa }_y$, the data owner derives a random number y in ${\mathbb{Z}}_q$. The data owner splits the file into n blocks, each of which contains s symbols in ${\mathbb{Z}}_q$, and derives a $\mathsf{PoWC}$ tag for each file block (for $1\le i\le n$):

  $${\sigma }_i=PR{F}_{\kappa }\left(i\right)+y\sum _{j=1}^s{\alpha }_j{m}_{ij}.$$
  The $\mathsf{auxi}=\{{\sigma }_1,{\sigma }_2,...,{\sigma }_n,{\alpha }_1,{\alpha }_2,...,{\alpha }_s\}$ will be sent to the cloud server.
• $Q\leftarrow \mathsf{PoWC}.\mathsf{challenge}\left(\right)$: The verifier checks whether the prover really possesses a file f. Checking each file block will be expensive, especially when the file is large in size. Instead, the verifier can check a random subset of c blocks (The verifier will check all the blocks if the file is small in size, e.g., having no more than 460 4 KB blocks.), which can ensure with high probability that the prover will not be able to pass the verification if it does not possess the entire file, when c is large enough [34]. The verifier picks a random c-element subset I of the set [1, n] and, for each $i\in I$, a random element $v_i$ is picked from ${\mathbb{Z}}_q$. The $Q=\left\{(i,v_i)\right\}$ will be sent to the prover. To prevent the prover from knowing $\left\{{\alpha }_j\right|1\le j\le s\}$, the cloud server sends $\left\{g^{{\alpha }_j}\right|1\le j\le s\}$ to the prover.
• $\mathsf{proof}\leftarrow \mathsf{PoWC}.\mathsf{Prove}(Q,f):$ The prover applies $\mathsf{MLE}$ over the file f, generating $\kappa$ and ${\kappa }_y$. Using ${\kappa }_y$, the prover computes y. Based on the received Q, the prover computes a $\mathsf{PoWC}$ proof as (for $1\le j\le s$):

  $${\mu }_j=y\sum _{(i,v_i)\in Q}{v}_i{m}_{ij}+x_j,$$

  where $x_j\in {\mathbb{Z}}_q$ is a random number picked by the prover for masking the proof. The prover also computes:

  $$tail=g^{{\displaystyle \sum _{(i,vi)\in Q}}{v}_{i}PR{F}_{\kappa }\left(i\right)}{(\prod _{j=1}^s{g}^{{\alpha }_j{x}_j})}^{-1}.$$
  Then, $\mathsf{proof}=(\left\{{\mu }_j\right|1\le j\le s\},tail)$ is returned to the verifier.
• $\{0,1\}\leftarrow \mathsf{PoWC}.\mathsf{Verify}(\mathsf{auxi},Q,\mathsf{proof})$: The algorithm returns “1” if the equation

  $$g^{{\displaystyle \sum _{(i,v_i)\in Q}}{v}_i{\sigma }_i}=tail·g^{{\displaystyle \sum _{j=1}^s}{\alpha }_j{\mu }_j}$$

  holds taking $\mathsf{auxi},Q$ and $\mathsf{proof}$ as input. Otherwise, the algorithm returns “0”.

4.2. Design Rationale of SEDER

There are several key designs in SEDER, as listed in the following:

First, we rely on $\mathsf{MLE}$ to ensure a file encrypted by different data owners is always deduplicable. $\mathsf{MLE}$ guarantees that different data owners who possess an identical file can always generate an identical encryption key.

Second, we design novel techniques that can allow the client and the server to identify duplicate content stored in them even though they hold the content in a different format, i.e., the client stores plaintext of the content while the server stores ciphertext of the content. An immediate solution is, during deduplication, the client encrypts the plaintext of the file, computes a checksum over the encrypted file, and sends this checksum to the server for comparison. This could be very expensive especially when the file is large in size. An improvement could be that the initial data owner who uploads the file initially also computes a checksum over the plaintext of the file, and stores this checksum in the server, and, during deduplication, the client can simply send the checksum computed from the plaintext of the data. This improvement, however, is insecure because, by knowing the checksum of the original data, the server may brute-force the file content due to the limited content space of a file. Fortunately, the encryption key derived through $\mathsf{MLE}$ can be used to protect the checksum value of plaintext as well. Our solution is that the initial data owner encrypts the checksum (which is usually small in size) over the plaintext using the $\mathsf{MLE}$ key, and the encrypted checksum will be sent to the server. This can prevent the server from performing the brute-force attack since it cannot have access to the $\mathsf{MLE}$ key. In addition, during the deduplication, the client can compute the checksum over the plaintext of the data, encrypt it using the derived $\mathsf{MLE}$ key, and send the encrypted checksum to the server for comparison.

Third, we use $\mathsf{AONT}$ and $\mathsf{DRE}$ together to support efficient re-encryption of the outsourced file. Specifically, given a file, we apply $\mathsf{MLE}$, obtaining the $\mathsf{MLE}$ ciphertext. $\mathsf{MLE}$ ensures that the same ciphertext will be generated from different users if the file content is the same. Then, $\mathsf{AONT}$ is applied to $\mathsf{MLE}$ ciphertext, generating a set of data blocks. Note that without fetching all the data blocks, the $\mathsf{MLE}$ ciphertext cannot be recovered thanks to the interesting property of $\mathsf{AONT}$. In this way, to re-encrypt a file, the data owner only needs to re-encrypt one data block, rather than all the data blocks. In addition, by leveraging $\mathsf{DRE}$, we can delegate the re-encryption process to the untrusted cloud server, without leaking the plaintext of the file. This is advantageous as we can eliminate the burden on the client who is supposed to be kept lightweight.

Finally, to ensure only the valid data owners are able to decrypt the data being re-encrypted, we perform the following: (1) We leverage $\mathsf{PoWC}$ to distinguish valid and invalid data owners. A valid data owner should be able to prove his/her ownership as he/she really possesses the file. When a data owner passes the verification, the cloud server will add him/her to the owner list of the file and provide him/her the assisting information needed for decrypting the file. (2) The data owner who re-encrypts the file will compute new assisting information that is needed to decrypt the file. The new assisting information will be re-propagated to the users in the owner list. The unauthorized users (e.g., the hackers which obtain the secret key) do not have the original file and will not be able to pass the $\mathsf{PoWC}$ to be added to the owner list.

4.3. Design Details of SEDER

Let $\lambda$, $\gamma$ and $\beta$ be the security parameters, ${\pi }_{\mathsf{DRE}}$ be a delegated re-encryption scheme that ${\pi }_{\mathsf{DRE}}=({\pi }_{\mathsf{DRE}}.\mathsf{SetUp}$, ${\pi }_{\mathsf{DRE}}.\mathsf{KeyGen},{\pi }_{\mathsf{DRE}}.\mathsf{Enc},{\pi }_{\mathsf{DRE}}.\mathsf{ReKeyGen}$, ${\pi }_{\mathsf{DRE}}.\mathsf{ReEnc}$,

${\pi }_{\mathsf{DRE}}.\mathsf{Dec})$. ${\pi }_{\mathsf{sym}}$ is a symmetric encryption scheme such that ${\pi }_{\mathsf{sym}}=({\pi }_{\mathsf{sym}}.\mathsf{KeyGen}$, ${\pi }_{\mathsf{sym}}.\mathsf{Enc},{\pi }_{\mathsf{sym}}.\mathsf{Dec})$, and ${\pi }_{\mathsf{asym}}$ is an asymmetric encryption scheme such that ${\pi }_{\mathsf{asym}}=({\pi }_{\mathsf{asym}}.\mathsf{KeyGen},{\pi }_{\mathsf{asym}}.\mathsf{Enc},{\pi }_{\mathsf{asym}}.\mathsf{Dec})$. Let P denote the $\mathsf{PoWC}$ scheme such that $P=(P.\mathsf{Init},P.\mathsf{chal},P.\mathsf{Prove},P.\mathsf{Verify})$. Let $H_1$ be a cryptographic hash function: $H_1:{\{0,1\}}^{*}\to {\{0,1\}}^{\lambda }$. In the following, we describe the design details of SEDER, which contains six phases: $\mathsf{SetUp}$, $\mathsf{PreUpload}$, $\mathsf{Upload}$, $\mathsf{Update}$, $\mathsf{Download}$ and $\mathsf{Delete}$.

• $\underline{\mathsf{SetUp}}$: This is to bootstrap the system parameters, and to initialize cryptographic parameters for data owners and cloud server. The system runs ${\pi }_{\mathsf{DRE}}.\mathsf{SetUp}\left(1^{\gamma }\right)$ to initialize the system parameters. In addition,
  • Data owner ($\mathsf{O}$): Each data owner ${\mathsf{O}}_i$ runs the key generation algorithm of asymmetric encryption scheme to generate the public and private key pair by running the algorithm: $({\pi }_{\mathsf{asym}}.{\mathsf{pk}}_{{\mathsf{O}}_i},{\pi }_{\mathsf{asym}}.{\mathsf{sk}}_{{\mathsf{O}}_i})\leftarrow {\pi }_{\mathsf{asym}}.\mathsf{KeyGen}\left(1^{\beta }\right)$.
  • Cloud server ($\mathsf{CS}$): It generates the public/private key pair by running the key generation algorithm of the asymmetric encryption scheme:
    $({\pi }_{\mathsf{asym}}.{\mathsf{pk}}_{\mathsf{CS}},{\pi }_{\mathsf{asym}}.{\mathsf{sk}}_{\mathsf{CS}})\leftarrow {\pi }_{\mathsf{asym}}.\mathsf{KeyGen}\left(1^{\beta }\right)$.

• $\underline{\mathsf{PreUpload}}$: The $\mathsf{PreUpload}$ phase is run by the data owner ${\mathsf{O}}_i$ before uploading a file f to $\mathsf{CS}$. ${\mathsf{O}}_i$ derives two keys $k_f$ and $k_c$ by applying $\mathsf{MLE}$ over f. ${\mathsf{O}}_i$ computes a checksum of f by: $checksu{m}_f={\pi }_{\mathsf{sym}}.\mathsf{Enc}(k_c,H_1\left(f\right))$.

• $\underline{\mathsf{Upload}}$: Data owner ${\mathsf{O}}_i$ sends an upload request ($checksu{m}_f$, $upload$) to the cloud server $\mathsf{CS}$, indicating that he/she wants to upload f. $\mathsf{CS}$ and ${\mathsf{O}}_i$ interact to perform the following operations:

• Case 1—$checksu{m}_f$ does not exist in $\mathsf{CS}$: In this case, ${\mathsf{O}}_i$ will upload the entire file f to $\mathsf{CS}$ following these steps:
  • ${\mathsf{O}}_i$ runs $P.\mathsf{Init}\left(f\right)$, generating $\mathsf{auxi}$.
  • ${\mathsf{O}}_i$ encrypts f by running $\mathsf{ct}\leftarrow {\pi }_{\mathsf{sym}}.\mathsf{Enc}(k_f,f)$.
  • ${\mathsf{O}}_i$ generates a secret key by running: ${\pi }_{\mathsf{DRE}}.{\mathsf{sk}}_i\leftarrow {\pi }_{\mathsf{DRE}}.\mathsf{KeyGen}\left({\mathsf{O}}_i\right)$.
  • ${\mathsf{O}}_i$ splits $\mathsf{ct}$ into l blocks: $\mathsf{ct}={\mathsf{ct}}_1\left|\right|{\mathsf{ct}}_2\left|\right|\dots \left|\right|$ ${\mathsf{ct}}_l$, and applies $\mathsf{AONT}$ transform on $\mathsf{ct}$, generating $l^{\prime }$ blocks, such that ${\mathsf{ct}}^{\prime }\leftarrow \mathsf{AONT}\left(\mathsf{ct}\right)$ where ${\mathsf{ct}}^{\prime }={\mathsf{ct}}_1^{\prime }\left|\right|{\mathsf{ct}}_2^{\prime }\left|\right|\dots \left|\right|{\mathsf{ct}}_{l^{\prime }}^{\prime }$ and $l^{\prime }\ge l$.
  • ${\mathsf{O}}_i$ randomly selects a data block ${\mathsf{ct}}_z^{\prime }$ from ${\mathsf{ct}}_1^{\prime },\dots ,{\mathsf{ct}}_{l^{\prime }}^{\prime }$ and encrypts it by running: $c={\pi }_{\mathsf{DRE}}.\mathsf{Enc}({\pi }_{\mathsf{DRE}}.{\mathsf{sk}}_i,{\mathsf{ct}}_z^{\prime })$. The final ciphertext is: ${\mathsf{ct}}_{\mathsf{Upload}}={\mathsf{ct}}_1^{\prime }\left|\right|\dots \left|\right|{\mathsf{ct}}_{z-1}^{\prime }\left|\right|c\left|\right|$${\mathsf{ct}}_{z+1}^{\prime }\left|\right|\dots \left|\right|{\mathsf{ct}}_{l^{\prime }}^{\prime }$.
  • ${\mathsf{O}}_i$ encrypts ${\pi }_{\mathsf{DRE}}.{\mathsf{sk}}_i$ using symmetric encryption with $k_f$:
    ${\mathsf{ct}}_{\mathsf{sym}}^{*}={\pi }_{\mathsf{sym}}.\mathsf{Enc}(k_f,{\pi }_{\mathsf{DRE}}.{\mathsf{sk}}_i)$, and further encrypts ${\mathsf{ct}}_{\mathsf{sym}}^{*}$ using asymmetric encryption with $\mathsf{CS}$’s public key: ${\mathsf{ct}}_{\mathsf{asym}}={\pi }_{\mathsf{asym}}.\mathsf{Enc}({\mathsf{pk}}_{\mathsf{CS}},{\mathsf{ct}}_{\mathsf{sym}}^{*})$.
  • ${\mathsf{O}}_i$ sends to the cloud server $\mathsf{auxi}$, ${\mathsf{ct}}_{\mathsf{Upload}}$, and ${\mathsf{ct}}_{\mathsf{asym}}$.
  • $\mathsf{CS}$ organizes the received information in the format $<checksu{m}_f$, ${\mathsf{ct}}_{\mathsf{Upload}}$, $\mathsf{auxi}$, ${\mathsf{ct}}_{\mathsf{asym}}$, owner list $l_{{\mathsf{ct}}_{\mathsf{Upload}}}>$. By decrypting ${\mathsf{ct}}_{\mathsf{asym}}$ using ${\pi }_{\mathsf{asym}}.{\mathsf{sk}}_{\mathsf{CS}}$, $\mathsf{CS}$ obtains the assisting information ${\mathsf{ct}}_{\mathsf{sym}}^{*}$ The owner list $l_{{\mathsf{ct}}_{\mathsf{Upload}}}$ is initialized as $\left\{{\mathsf{O}}_i\right\}$.

• Case 2—$checksu{m}_f$ exists in $\mathsf{CS}$: Since the file has been stored by $\mathsf{CS}$, it is necessary to perform $\mathsf{PoWC}$ to verify whether ${\mathsf{O}}_i$ really possesses this file:
  • $\mathsf{CS}$ runs $Q\leftarrow P.\mathsf{chal}\left(\right)$, and sends Q and $\left\{g^{{\alpha }_j}\right|1\le j\le s\}$ to ${\mathsf{O}}_i$. Note that $\left\{g^{{\alpha }_j}\right|1\le j\le s\}$ is part of the $\mathsf{auxi}$ (Section 4.1.1).
  • ${\mathsf{O}}_i$ computes a $\mathsf{PoWC}$ proof by running $\mathsf{proof}\leftarrow P.\mathsf{Prove}(Q,f)$, and sends $\mathsf{proof}$ back to $\mathsf{CS}$.
  • $\mathsf{CS}$ verifies $\mathsf{proof}$ by running $P.\mathsf{Verify}(\mathsf{auxi},Q,\mathsf{proof})$. If the output is ‘1’, $\mathsf{CS}$ appends ${\mathsf{O}}_i$ to the owner list ($l_{{\mathsf{ct}}_{\mathsf{Upload}}}$) and sends the assisting information of f, i.e., ${\mathsf{ct}}_{\mathsf{sym}}^{*}$, to ${\mathsf{O}}_i$. Otherwise, $\mathsf{CS}$ rejects ${\mathsf{O}}_i$. Note that ${\mathsf{ct}}_{\mathsf{sym}}^{*}$ will be encrypted using ${\mathsf{O}}_i$’s public key ${\mathsf{pk}}_{{\mathsf{O}}_i}$ and securely distributed to ${\mathsf{O}}_i$, and ${\mathsf{O}}_i$ can use private key ${\mathsf{sk}}_{{\mathsf{O}}_i}$ for decryption.

• $\underline{\mathsf{Update}}$: When ${\mathsf{O}}_j$, a data owner in the owner list $l_{{\mathsf{ct}}_{\mathsf{Upload}}}$, suspects $k_f$ or ${\pi }_{\mathsf{DRE}}.s{k}_i$ (i.e., the old secret key used for encrypting $c^{\prime }$ in ${\mathsf{ct}}_{\mathsf{Upload}}$) is leaked, only a small part of ciphertext rather than the entire file will be re-encrypted by ${\mathsf{O}}_j$ as follows:
  • ${\mathsf{O}}_j$ decrypts ${\mathsf{ct}}_{\mathsf{sym}}^{*}$ using $k_f$, obtaining ${\pi }_{\mathsf{DRE}}.{\mathsf{sk}}_i$, where i denotes the data owner which encrypts the file before re-encryption.
  • By using ${\pi }_{\mathsf{DRE}}.{\mathsf{sk}}_i$ and his/her own secret key ${\pi }_{\mathsf{DRE}}.{\mathsf{sk}}_j$, ${\mathsf{O}}_j$ generates the re-encryption key by running $r{k}_{i\to j}\leftarrow {\pi }_{\mathsf{DRE}}.\mathsf{ReKeyGen}({\pi }_{\mathsf{DRE}}.{\mathsf{sk}}_i,{\pi }_{\mathsf{DRE}}.{\mathsf{sk}}_j)$. ${\mathsf{O}}_j$ encrypts ${\pi }_{\mathsf{DRE}}.{\mathsf{sk}}_j$ using $k_f$: ${\mathsf{ct}}_{\mathsf{sym}}^{\#}={\pi }_{\mathsf{sym}}.\mathsf{Enc}(k_f,{\pi }_{\mathsf{DRE}}.{\mathsf{sk}}_j)$, and then encrypts ${\mathsf{ct}}_{\mathsf{sym}}^{\#}$ using $\mathsf{CS}$’s public key: ${\mathsf{ct}}_{\mathsf{asym}}^{\prime }={\pi }_{\mathsf{asym}}.\mathsf{Enc}({\mathsf{pk}}_{\mathsf{CS}},{\mathsf{ct}}_{\mathsf{sym}}^{\#})$. ${\mathsf{ct}}_{\mathsf{asym}}^{\prime }$ and $r{k}_{i\to j}$ are sent to $\mathsf{CS}$.
  • $\mathsf{CS}$ runs $c^{\prime }\leftarrow {\pi }_{\mathsf{DRE}}.\mathsf{ReEnc}(r{k}_{i\to j},c)$ and replaces c with $c^{\prime }$. In addition,$\mathsf{CS}$ replaces ${\mathsf{ct}}_{\mathsf{sym}}^{*}$ with ${\mathsf{ct}}_{\mathsf{asym}}^{\#}$, which is decrypted from ${\mathsf{ct}}_{\mathsf{sym}}^{\prime }$, and distributes ${\mathsf{ct}}_{\mathsf{sym}}^{\#}$ to valid owners in $l_{{\mathsf{ct}}_{\mathsf{Upload}}}$. Note that a revoked owner will not be able to obtain ${\mathsf{ct}}_{\mathsf{sym}}^{\#}$, and is not able to decrypt the re-encrypted data any more.

• $\underline{\mathsf{Download}}$: ${\mathsf{O}}_i$ sends a download request ($checksu{m}_f$, $download$) to $\mathsf{CS}$ if he/she wants to retrieve f. $\mathsf{CS}$ then checks whether ${\mathsf{O}}_i$ is in the owner list $l_{{\mathsf{ct}}_{\mathsf{Upload}}}$ or not. If ${\mathsf{O}}_i$ is in the owner list, $\mathsf{CS}$ will respond with ${\mathsf{ct}}_{\mathsf{Upload}}$, and ${\mathsf{O}}_i$ uses the file key and the assisting information (e.g., ${\mathsf{ct}}_{\mathsf{sym}}^{*}$, or ${\mathsf{ct}}_{\mathsf{sym}}^{\#}$ if the data have been re-encrypted) to decode ${\mathsf{ct}}_{\mathsf{Upload}}$. Otherwise, $\mathsf{CS}$ will reject this download request.
• $\underline{\mathsf{Delete}}$: When $\mathsf{CS}$ receives a delete request ($checksu{m}_f$, $delete$) from a data owner ${\mathsf{O}}_k$, if ${\mathsf{O}}_k$ is in the owner list, $\mathsf{CS}$ will remove ${\mathsf{O}}_k$ from the owner list $l_{{\mathsf{ct}}_{\mathsf{Upload}}}$ of file f, i.e., ${\mathsf{O}}_k$ has been revoked. If $l_{{\mathsf{ct}}_{\mathsf{Upload}}}$ turns empty, $\mathsf{CS}$ will delete ${\mathsf{ct}}_{\mathsf{Upload}}$ and $checksu{m}_f$, $\mathsf{auxi}$. Otherwise, the re-encryption process (i.e., $\mathsf{Update}$) should be invoked so that the revoked data owner is not able to decrypt the data any more.

5. Analysis and Discussion

5.1. Security Analysis

Security of SEDER is captured in the following Lemmas and Theorems.

Lemma 1.

The cloud server cannot learn the original file by having access to its ciphertext and the encrypted assisting information.

Proof. (Sketch) The encrypted file after $\mathsf{AONT}$ transform, i.e., ${\mathsf{ct}}_{\mathsf{Upload}}$, and the assisting information, i.e., ${\mathsf{ct}}_{\mathsf{sym}}^{*}$ or ${\mathsf{ct}}_{\mathsf{sym}}^{\#}$, are stored in the cloud storage. Without having access to the file key $k_f$ derived through $\mathsf{MLE}$, the cloud server cannot decrypt any assisting information, and hence cannot have access to the secret key which is required to decrypt block c (or $c^{\prime }$). Due to $\mathsf{AONT}$, without having obtained all the blocks, the cloud server will not be able to decode ${\mathsf{ct}}^{\prime }$ to obtain the encrypted original file $\mathsf{ct}$, let alone the original file f. □

Lemma 2.

The cloud server cannot learn the original file from $checksu{m}_f$.

Proof. (Sketch) $checksu{m}_f$ is obtained by encrypting the hash value of the file f using a file key $k_c$. Since the cloud server is not able to have access to $k_c$ (the $\mathsf{MLE}$ used to derive $k_c$ is assumed to be secure, and without having access to the original file, the cloud server will not be able to derive $k_c$), it will not be able to decrypt the cipher to obtain the hash value of f, considering the symmetric encryption is secure. Without the hash value of the file, the cloud server is not able to perform the brute-force attack to infer the file. □

Lemma 3.

The cloud server cannot learn the original file when performing $\mathsf{DRE}$.

Proof. (Sketch) During each run of proxy re-encryption, the cloud server (as a re-encryption proxy here) can observe: (1) $c_i=m{g}^{k_i}$; and (2) $r{k}_{i\to j}=g^{k_j-k_i}$. There are two potential attack cases. Case 1: the cloud server tries to learn m using knowledge obtained from one run of proxy re-encryption. The cloud server will not be able to have access to $k_i$, $g^{k_i}$, $k_j$, $g^{k_j}$, and it is clear that the cloud server cannot learn m from the knowledge of (1) and (2) since there are three unknowns and two equations. The probability of guessing m will be no larger than $\frac{1}{2^q}$ for a q-bit m, which is negligibly small for a large enough q. Case 2: the cloud server tries to learn m by accumulating knowledge from multiple runs of proxy re-encryption. By accumulating knowledge from the first run of the proxy re-encryption, the cloud server cannot learn m since there are three unknowns but only two equations. For each following run, the data owner will pick a completely different random key, and send a new re-encryption key to the cloud server. Therefore, the cloud server will obtain an additional equation, along with a new unknown. In other words, the additional knowledge accumulated from each following run of proxy re-encryption will not provide the cloud server with any additional advantage of computing m. □

Lemma 4.

The cloud server cannot learn the original file through performing $\mathsf{PoWC}$.

Proof. (Sketch) The cloud server can have access to: (1) $\mathsf{auxi}$, which consists of $\mathsf{PoWC}$ tags and $\left\{{\alpha }_j\right|1\le j\le s\}$, provided by the data owner who initially uploads the file; (2) $\mathsf{proof}$, which includes $\left\{{\mu }_j\right|1\le j\le s\}$ and $tail$, obtained during each $\mathsf{PoWC}$ execution.

(1) We first show that, by having access to $\mathsf{auxi}$, the cloud server cannot obtain the original file. By having access to the set of n$\mathsf{PoWC}$ tags and $\left\{{\alpha }_i\right|1\le i\le s\}$, equivalently, the cloud server can have access to n linear equations and $(ns+n+1)$ unknowns (i.e., $m_{11}$, $m_{12}$,…, $m_{1s}$, $m_{21}$, $m_{22}$,…, $m_{2s}$,…, $m_{n1}$, $m_{n2}$,…, $m_{ns}$, $PR{F}_{\kappa }\left(1\right)$, $PR{F}_{\kappa }\left(2\right)$,…, $PR{F}_{\kappa }\left(n\right)$, y). The cloud server is not able to compute the $(ns+n+1)$ unknowns using the n linear equations. The cloud server may try to guess the file content (due to the limited content space of a file) in a brute-force manner and, to use each guessed file content to derive $\kappa$ and y using $\mathsf{MLE}$. This will not be feasible since both $\kappa$ and y are directly or indirectly derived by $\mathsf{MLE}$, which can resist against the offline brute-force attack. The only option for the cloud server is to guess each file content, and to utilize the n linear equations to compute the remaining $PR{F}_{\kappa }\left(1\right)$, $PR{F}_{\kappa }\left(2\right)$,…, $PR{F}_{\kappa }\left(n\right)$, and y based on the guessed file content. However, the number of unknowns (i.e., n + 1) is more than the number of linear equations (i.e., n), which makes the n linear equations unsolvable.

(2) We then show that, by accumulating PoW proofs after each PoW execution, the cloud server is still not able to learn the original file. A few key points are important for our security: First, If the PoW check fails, the accumulated PoW proof should not help the server, since the data owner is not supposed to possess the original file. Second, the cloud server will strictly follow the PoW protocol during each PoW execution (i.e., honest). This includes generating a random challenge during each PoW execution. Third, the prover will not collude with the verifier, and will mask each ${\mu }_j$ (where $1\le j\le s$) with a newly generated random number. After each successful PoW execution, the cloud server will accumulate a new PoW proof, which includes ${\mu }_1$, ${\mu }_2$,…, ${\mu }_s$ as well as $tail$:

${\mu }_1\leftarrow y{\displaystyle \sum _{(i,v_i)\in Q}}{v}_i{m}_{i1}+x_1$

${\mu }_2\leftarrow y{\displaystyle \sum _{(i,v_i)\in Q}}{v}_i{m}_{i2}+x_2$

…

${\mu }_s\leftarrow y{\displaystyle \sum _{(i,v_i)\in Q}}{v}_i{m}_{is}+x_s$

$tail\leftarrow g^{{\displaystyle \sum _{(i,v_i)\in Q}}{v}_{i}PR{F}_{\kappa }\left(i\right)}{({\displaystyle \prod _{j=1}^s}{g}^{{\alpha }_j{x}_j})}^{-1}$

Since ${\mu }_j$ ($1\le j\le s$) is masked by newly generated random number $x_j$, the number of new linear equations brought by ${\mu }_1$, ${\mu }_2$,…, ${\mu }_s$ is equal to the number of new unknowns. Therefore, the set of $\left\{{\mu }_j\right|1\le j\le s\}$ alone does not bring any advantage to the cloud server for computing $m_{ij}$. We further show that, by utilizing $tail$, the cloud server also gains negligible advantage of computing $m_{ij}$. Because of hardness of DLP, to use $tail$, the cloud server needs to guess $x_j$ ($1\le j\le s$) and $\kappa$, and to verify correctness of each guessing using $tail$. The probability for a successful guessing will be smaller than $\frac{1}{q^s}$, which is negligibly small if q is large enough. □

Lemma 5.

A malicious entity which does not possess the entire file cannot pass the $\mathsf{PoWC}$ verification.

Proof. (Sketch) In the following, we first prove that the PoW verification process is correct. We further show that, by checking a random subset of the entire file, the verifier can ensure that the prover really possesses the entire file with a high probability (note that, if the file size is small, the verifier will check all the file blocks, which can always ensure that the prover really possesses the entire file). Lastly, we show that, if the PoW verification can be passed successfully, the verifier can always ensure that the prover possesses the challenged blocks.

We first show correctness of the $\mathsf{PoWC}$ verification process as follows:

$$\begin{array}{cc}\hfill g^{{\displaystyle \sum _{(i,v_i)\in Q}}{v}_i{\sigma }_i}& =g^{{\displaystyle \sum _{(i,v_i)\in Q}}{v}_i(PR{F}_{\kappa }\left(i\right)+y{\displaystyle \sum _{j=1}^s}{\alpha }_j{m}_{ij})}\hfill \\ \hfill & =g^{{\displaystyle \sum _{(i,v_i)\in Q}}{v}_{i}PR{F}_{\kappa }\left(i\right)+{\displaystyle \sum _{j=1}^s}{\alpha }_j·y{\displaystyle \sum _{(i,v_i)\in Q}}{v}_i{m}_{ij}}\hfill \\ \hfill & =g^{{\displaystyle \sum _{(i,v_i)\in Q}}{v}_{i}PR{F}_{\kappa }\left(i\right)+{\displaystyle \sum _{j=1}^s}{\alpha }_j({\mu }_j-x_j)}\hfill \\ \hfill & =g^{{\displaystyle \sum _{(i,v_i)\in Q}}{v}_{i}PR{F}_{\kappa }\left(i\right)}{\displaystyle \prod _{j=1}^s}{g}^{{\alpha }_j({\mu }_j-x_j)}\hfill \\ \hfill & =g^{{\displaystyle \sum _{(i,v_i)\in Q}}{v}_{i}PR{F}_{\kappa }\left(i\right)}{\displaystyle \prod _{j=1}^s}\frac{g^{{\alpha }_j{\mu }_j}}{g^{{\alpha }_j{x}_j}}\hfill \\ \hfill & =tail·{\displaystyle \prod _{j=1}^s}{g}^{{\alpha }_j{\mu }_j}\hfill \end{array}$$

We then show that, by challenging a random subset of blocks among the entire file, and if a malicious data owner does not possess the entire file, the cloud server can detect it with a high probability. According to PDP [34], if the adversary only possesses w proportion of an n-block file, when being challenged, a random subset of c blocks out of n blocks, the probability that the verifier can detect the misbehavior is: $P=1-\frac{\left(\genfrac{}{}{0pt}{}{wn}{c}\right)}{\left(\genfrac{}{}{0pt}{}{n}{c}\right)}$, and $1-w^c\le P\le 1-{\left(\frac{wn-c+1}{n-c+1}\right)}^c$. The lower bound of the P is $1-w^c$, which means, when c is large enough, $w^c\to 0$, and $P\to 1$.

Finally, we show that, if the prover loses one of the challenged blocks, it will not be able to pass the PoW check. During the PoW verification, all the PoW tags ${\sigma }_i$, where $1\le i\le n$ are unknown to the prover, and hence $g^{{\displaystyle \sum _{(i,v_i)\in Q}}{v}_i{\sigma }_i}$ is also unknown. If the prover is missing one block being challenged, it needs to guess this block when computing the PoW proof ${\mu }_1$, ${\mu }_2$,…, ${\mu }_s$.

The resulting PoW proof can successfully pass the PoW check with a probability no more than $\frac{1}{q}$. This probability is negligibly small for a large enough prime q. Therefore, we can conclude that the prover is not able to pass the PoW check without actually possessing all the blocks being challenged during each PoW execution. □

Theorem 1.

SEDER is secure under our adversarial model.

Proof. (Sketch) SEDER is secure since the following security goals can be achieved: (1) the cloud server cannot learn anything about the original file f; and (2) a malicious entity which does not possess f cannot pass the $\mathsf{PoWC}$ check; and (3) a malicious entity cannot learn anything about f. The first security goal can be captured by Lemmas 1–4, and the second security goal can be ensured by Lemma 5. For the last security goal, since a malicious entity (including a revoked data owner which has deleted the original file) cannot pass the $\mathsf{PoWC}$ check, it can obtain neither the encrypted data nor the updated decryption key, and hence is not able to learn the original file f. □

5.2. Discussion

• Zero-day attack. SEDER is vulnerable to the zero-day attack, in which the key is leaked and the re-encryption has not been performed. During this period, the adversary can have access to the original file using the obtained key materials. This seems to be unavoidable and currently not a good solution for mitigating such a strong attack.
• The nature of the storage being supported by SEDER. Currently, SEDER only supports archival storage [20,34,35,36]. It can be extended to support dynamic storage (i.e., supporting dynamic operations like insert, delete, and modify [27,37,38,39]) in the future.

6. Experimental Evaluation

6.1. Experimental Setup

We have experimentally evaluated overhead of each major operation in SEDER. We chose the security parameters as: $\gamma =p=q=128$, $\beta =1024$, and $\lambda =256$. The length of the file key $k_f$ and $k_c$ is 128 bits. The symmetric and asymmetric encryption were instantiated by AES-128 and RSA-1024, respectively. The hash function was instantiated using SHA-256. We instantiated the secure $\mathsf{MLE}$ following the idea of DupLESS [10]. OpenSSL-1.1.0e [40] was used for the major cryptographic operations. Throughout the experiment, the client and the cloud server both ran on a local computer with Intel i5-6300 (2.5 GHz) CPU and 8 GB RAM. The computational overhead in $\mathsf{PreUpload}$, $\mathsf{Upload}$, $\mathsf{Update}$, and $\mathsf{Download}$ phases are evaluated for different file sizes, and the experimental results are averaged over 10 runs. When evaluating the $\mathsf{Upload}$ phase, we varied a and b, where a is the file block size (in bytes) and b is the symbol size (in bytes).

6.2. Experimental Results

In the following, we evaluate the performance of SEDER in different phases. To the best of our knowledge, among existing PoW schemes on encrypted cloud data [17,18,31], as shown in

Table 1. Comparison with other deduplication schemes. (Hur [41] and REED [15] are server-side deduplication schemes which do not include the PoW process).

Proposals	Data Confidentiality	Ownership Validation Base	Resistance to the Brute-Force Attack	Key Update (Complexity)
Halevi [16]	×	Merkle-tree of the original file	×	$N/A$
Xiong [18]	✓	Encrypted file blocks	×	$O\left(n\right)$
Ding [17]	✓	Hash value of the file	×	$O\left(n\right)$
PoWIS [31]	✓	Merkle-tree of the original file	✓	$N/A$
Hur [41]	✓	$N/A$	$N/A$	$O\left(n\right)$
REED [15]	✓	$N/A$	$N/A$	$O\left(1\right)$
Our scheme	✓	Homomorphic verifiable tags of the original file	✓	$O\left(1\right)$

, PoWIS is the solely proposal that can achieve the same security level with our $\mathsf{PoWC}$. First, due to relying on the hash value of the original file to find out whether the file has existed in the cloud server before uploading, the PoW process in [17,18] are vulnerable to the brute-force attack. In addition, since the PoW design in [17] works relying on the hash value of the file, it cannot provide concrete ownership guarantees (the vulnerability has been identified in [16]). In this case, the PoWIS [31] and our $\mathsf{PoWC}$ are the two more secure PoW schemes on encrypted cloud data than the counterparts [17,18] for the client-side deduplication system. Therefore, for the $\mathsf{Upload}$ phase, we compare our PoWC with the existing scheme PoWIS [31], which can also enable the PoW over the outsourced encrypted data securely. For the $\mathsf{Update}$ phase, we compare the performance of our re-encryption process (i.e., DRE) with that in REED [15], which consumes much less bandwidth and computational resources compared to the existing re-encryption designs in [17,18,41] by taking full advantage of $\mathsf{AONT}$, but completely relies on the client for the re-encryption process due to the nature of the server-side deduplication.

• PreUpload. The data owner obtains secure $\mathsf{MLE}$ keys in this phase. The secure $\mathsf{MLE}$, i.e., DupLESS, requires interactions between the data owner and an independent key server. We therefore assessed the computational overhead in both the data owner and the key server. As shown in Figure 1, the computational cost in the key server is constant. On the contrary, the computational cost for the client (i.e., the data owner) is linear with the file size. This is because the data owner needs to first compute a hash value of the original file, and such a cost depends on the file size.
• Upload. The computational cost for Case 1 and Case 2 of the $\mathsf{Upload}$ phase (Section 4.3) are shown in Figure 2 and Figure 3, respectively.

In Case 1, to enable $\mathsf{PoWC}$, the initial data owner needs to select a set of secret coefficients $\left\{{\alpha }_j\right|1\le j\le s\}$ and to compute $\mathsf{PoWC}$ tags. Then, the data owner encrypts the file and performs $\mathsf{AONT}$ on the encrypted file. From Figure 2, we can observe that: (1) The computation for generating the secret coefficients and computing $g^{{\alpha }_j}$ is independent from the file size. In addition, this computation is mainly determined by s, which is $\frac{a}{b}$. (2) The computation for generating $\mathsf{PoWC}$ tags grows linearly with the file size. Additionally, for the fixed file size, the computation for different testing cases is: $(a=2048,b=10)>(a=2048,b=20)\approx (a=4096,b=20)$. This is because, the computation for generating $\mathsf{PoWC}$ tags depends on the total number of symbols in a file, which $O(\frac{\left|F\right|}{b})$. (3) The computation for AES encryption and $\mathsf{AONT}$ transform is determined by the file size and approximately grow linearly with the file size.

In Case 2, the prover (i.e., a potential data owner) computes the $\mathsf{PoWC}$ proof, and the verifier (i.e., the cloud server) verifies correctness of the $\mathsf{PoWC}$ proof. From Figure 3, we can observe that: (1) Both the proof generation and verification can be performed in constant time thanks to the use of spot checking (i.e., only 460 randomly picked blocks instead of the entire file are checked [34]. (2) For the fixed file size, the computation needed for different testing cases are $(a=4096,b=20)\approx (a=2048,b=10)>(a=2048,b=20)$. This is because both the proof generation and verification are mainly determined by the number of symbols in a block, i.e., s, which is $\frac{a}{b}$.

Considering security, we compare the performance of our $\mathsf{PoWC}$ and PoWIS [31], which both allow PoW to be performed on the encrypted data with sufficient ownership guarantees and resistance to the brute-force attack. The comparison is shown in

Table 2. Performance comparison between PoWIS and $\mathsf{PoWC}$ in this work. PoWIS has a much better performance by using dedicated secure hardware, but it relies on the assumption that the cloud server has secure hardware equipped. The $\mathsf{PoWC}$ is purely based on cryptography, and does not rely on the aforementioned assumption.

	PoWIS [31]	$\mathsf{PoWC}$
Secure hardware required	✓	×
Generating PoW tag (file size in 16 MB)	0.33 s	1.3745 s
Generating PoW proofs (for 460 file blocks)	0.0242 s	0.4376 s
Verifying PoW proofs (for 460 file blocks)	0.014 s	0.2224 s

. We can observe that PoWIS is much more efficient than $\mathsf{PoWC}$ in tag generation, proof generation, and verification. This is mainly due to the support of secure hardware (i.e., Intel SGX) in PoWIS. On the contrary, $\mathsf{PoWC}$ is purely based on cryptography and does not require secure hardware as well as the trust on the secure hardware manufacturer. Secure hardware may not be equipped with the server, and hence PoWIS will have limited applications, but $\mathsf{PoWC}$ is a general solution which can be deployed on any general computing device. In addition, using secure hardware like Intel SGX will introduce extra overhead for performing platform attestation [42] to ensure the usage of secure hardware. This overhead may be large, e.g., more than 1 s [31].

• Update. A valid data owner will cooperate with the cloud server to re-encrypt the file if the key is leaked. The results for this phase are shown in Figure 4a.

We can observe that the computation in both the data owner and the cloud server is rather small (less than $0.1$ ms), compared to actually re-encrypting the entire file (which is 10–200 s as estimated from Figure 4b). In addition, both are independent from the file size because only a fixed part of the entire data needs to be re-encrypted.

Considering significant computational and bandwidth saving, we compare the performance of $\mathsf{DRE}$ and REED [15], both of which support the re-encryption in a cloud storage system by re-encrypting a small file block with fixed size rather than the entire file in [17,18,41]. The results are shown in

Table 3. Performance comparison between REED and our DRE. Note that the re-encrypted block is 64 bytes in size.

	REED [15]	Our $\mathsf{DRE}$
Computational cost in the client (ms)	57.21	0.092
Computational cost in the server (ms)	$N/A$	0.056

. We can observe that our $\mathsf{DRE}$, although introduces computational overhead to the server, has significantly less computation in the client side. This is because: (1) In our $\mathsf{DRE}$, the client only needs to re-encrypt the key, rather than the data; on the contrary, the client needs to re-encrypt the data in REED. (2) REED uses cipertext-policy attribute-based encryption (CP-ABE) in the re-encryption process, which contains computationally expensive pairing operations for fine-grained access control; on the contrary, our re-encryption process does not contain these expensive pairing operations to support a coarse-grained access control in re-encryption. A more fine-grained re-encryption scheme for SEDER could be our future work by taking fully advantage of the nature of the client-side deduplication.

• Download. To retrieve the file, a data owner needs to decrypt the re-encrypted block (the process is denoted as $DecRe$-$encBlock$ in Figure 4b), to perform the reverse operation of $\mathsf{AONT}$, and to further decrypt the resulted data to obtain the original file (denoted as $AESDecryption$ in Figure 4b). From Figure 4b, we can observe that: (1) The computation of decrypting the re-encrypted block is small (less than 6 ms) and remains constant. (2) The computation for $AESDecryption$ grows linearly with the file size.

7. Related Work

• Message-Locked Encryption ($\mathsf{MLE}$). $\mathsf{MLE}$ is a set of encryption algorithm that the encryption key is derived from the message being encrypted, which is formalized by Bellare et al. in [8]. Douceur et al. [9] proposed convergent encryption (CE), the first $\mathsf{MLE}$ scheme, in which the encryption key is the hash value of the file being encrypted, such that the same file possessed by different users can be encrypted to be same ciphertexts by identical encryption key. CE has been adopted in several online backup systems [43,44,45,46,47,48,49] for facilitating the performance of deduplication over data encrypted by different data owners. However, CE is vulnerable to the offline dictionary attack, since content space is usually predictable. To mitigate this security issue, several $\mathsf{MLE}$ schemes were proposed. Bellare et al. proposed DupLESS [10] by introducing an independent key server and limiting times for accessing the key server. Duan [11] proposed another secure $\mathsf{MLE}$ scheme based on distributed oblivious key generation. Liu et al. [12] proposed a $\mathsf{MLE}$ scheme without relying on any independent server by requiring the valid data owner to participate in authentication and use a same input Password-Authenticated-Key-Exchange (PAKE) to derive the final $\mathsf{MLE}$ key. The online dictionary attack is mitigated for the first time by allowing the valid data owner to limit times for performing key exchange with them.
• Proxy Re-Encryption. Blaze et al. [28] proposed proxy re-encryption for the first time, which requires a mutual trust between the delegator and its delegatees. Ateniese et al. [30] released a trust requirement with the cost that the re-encrypted ciphertext cannot be re-encrypted repeatedly. Canetti and Hohenberger [50] pointed out that the proxy re-encryption is vulnerable to the chosen-ciphertext attack (CCA) and the chosen-plaintext attack (CPA), and proposed a CCA-secure proxy re-encryption scheme, which, however, requires bidirectional trust among delegator and delegatees. Davidson et al. [51] presented two proxy re-encryption schemes based on matrix transformation, one is secure under standard CPA model requiring unidirectional trust between delegator and its delegatees, and the other one is secure in a stricter CCA model when the delegator and its delegatees can establish bidirectional trust. More recently, Ref. [52] identified a new security level for proxy re-encryption and adjusted existing schemes to fit in this new security definition. There are several works focusing on enhancing usability of existing proxy re-encryption schemes. For example, the a proxy re-encryption scheme in [53] is compatible with the hybrid encryption scenario at the cost of additional storage space for the proxy to store encrypted random masks for each delegatee.
• Deduplication and Proofs of Ownership (PoWs). Deduplication has been widely used in cloud storage. For significant bandwidth and storage saving, the client-side deduplication schemes [41,47,54,55,56] is investigated and used more than the server-side deduplication schemes in practice. ClearBox [57] is a transparent deduplication scheme, in which storage service providers can attest to users the number of owners of specific file transparently, so that users can share the fee for storing the same file. Li et al. [58] proposed $SecClou{d}^{+}$ to achieve data integrity and deduplication simultaneously. Tang et al. [59] performed data deduplication on a backup system with ciphertext-policy attribute based encryption (CP-ABE) enabled. For protecting privacy, the Message-Locked Encryption [8,9] was used in server-side deduplication. To mitigate the offline dictionary attack faced by CE, which is one of the most widely used $\mathsf{MLE}$ schemes, Bellare et al. proposed DupLESS [10] by introducing a key server and limiting the number of requests for obtaining a $\mathsf{MLE}$ key within a fixed time interval, which can mitigate the brute-force attack faced by the $\mathsf{MLE}$. Liu et al. [12] removed the additional independent key server at the cost of requiring at least one valid data owner to stay online when performing deduplication. Li et al. [47] proposed a deduplication scheme taking advantage of the hybrid cloud environment, in which the encryption keys are generated and managed by the private cloud server owned by the users, while the public cloud server provides storage service and server-side deduplication. Yao et al. [60] proposed a Hierarchical Privilege-Based Predicate Encryption ($HPBPE$) scheme based on the hierarchical encryption, which introduces a deduplication provider to check duplication based on user dynamic privileges of users without revealing any information about privilege to the cloud server. To further enhance the effectiveness of deduplication, some generalized deduplication schemes [61,62,63] are proposed by detecting and removing “similar” data rater than “identical” data using transformation functions, e.g., the Hamming code and the Revealing Encryption (RE), in traditional deduplication schemes.

To enable a secure client-side deduplication, the proof of ownership protocol is necessary since the cloud server needs to check whether the prover really possesses the file that has existed in the cloud storage without requiring the prover to upload the entire file again to manage ownership of the file correctly. The traditional Merkle tree based PoW [16] assumes that the cloud server is fully trusted and has access to the original file, which is not applicable to scenarios where the data owners have advanced security requirements, e.g., protecting confidentiality and copyright against the untrusted cloud server. To ensure data confidentiality, Puzio et al. proposed a client-side deduplication scheme [64] to remove redundant data by introducing a trusted third party (which is called “Metadata Magager”) to authenticate users that can perform deduplication checking for, however, specific users rather than across multiple users. In 2018, Xiong et al. [65] designed an authenticated deduplication by leveraging a role symmetric encryption (RSE) algorithm to accomplish fine-grained access control for deduplication. Xiong et al. [18,65], Ding et al. [17], and our previous work [19] proposed several client-side deduplication schemes including proofs of ownership on the encrypted cloud data, which, however, are problematic in security or performance due to using irrational commitment in ownership validation, e.g., the encrypted file blocks in [18,65], the hash value of the original file in [17], and the Merkle tree derived from the encrypted data. You et al. noticed this conflict and proposed a deduplication-friendly watermarking [32], in which the untrusted cloud server can validate ownership of the original file by having access to the watermarked file. An implementation of PoW [31] for encrypted cloud data by leveraging trusted hardware was proposed, which, however, requires the cloud server to support and enable specific trusted features.

However, data owner revocation is not well considered in the above deduplication schemes, which is quite common in the cloud storage environment. In this case, Kwon et al. [66] then designed a deduplication scheme specific for multimedia data based on randomized convergent encryption and privilege-based encryption. Hur et al. [41] proposed a novel server-side deduplication to support dynamic ownership management by leveraging the group key distribution techniques and randomized convergent encryption. Xiong et al. proposed a client-side deduplication scheme [18] allowing changing ownership dynamically based on their previous work [65]. Ding et al. proposed a client-side deduplication scheme [17] that enables dynamic ownership based on homomorphic encryption. However, the aforementioned schemes are expensive in computation and communication since the entire encrypted file needs to be updated when the re-encryption happens. REED [15,67] aimed at addressing the key revocation problem for the secure server-side deduplication in cloud storage efficiently. In order to efficiently replace old keys and re-encrypt the data, REED introduced two special $\mathsf{AONT}$ transforms derived from CAONT (CANOT is a special case of $\mathsf{AONT}$ transforms in which the key used for $\mathsf{AONT}$ transform is the hash value of the message being processed). Different from REED, our SEDER resolves the re-encryption problem for the client-side deduplication and further optimizes the performance of the re-encryption process by taking full advantage of the nature of the client-side deduplication.

Overall, our SEDER enables secure and efficient re-encryption for a cloud storage, in which the data owner collaborates with the cloud server to re-encrypt a small file block when the key needs to be updated, resulting in significant bandwidth and computational saving. The client-side deduplication is enabled in SEDER as well, which ensures data ownership and is resistant to the brute-force attack.

8. Conclusions

In this paper, we propose SEDER to enable an efficient and secure re-encryption scheme for client-side deduplication in cloud storage. We achieve efficiency by only re-encrypting a small proportion of the file and delegating the re-encryption process to the cloud server. We achieve security by incorporating a secure duplicate detection approach and a PoW scheme specifically for encrypted data. Security analysis and experimental results show that our design is applicable to the cloud storage system, since it ensures continuous data confidentiality with modest computational and communication overhead, which, specifically, is for the test data set. The prover and the cloud server spend no more than 0.85 s and 0.45 s, respectively, in performing the PoW, and the re-encryption process requires at most 0.092 milliseconds and 0.014 milliseconds for the users and the cloud server, respectively.