Enabling Transparent Deduplication andAuditing for Encrypted Data in Cloud

传统的安全去重方案要求用户使用特定的加密算法对外包文件进行加密，无法提供语义安全。用户也无法直接从去重中获益，因为实际存储成本与提供价格之间的关系仍然不透明。因此，用户可能不愿意通过使用语义安全算法加密他们的数据来与云合作。此外，数据完整性是云存储用户关心的重要问题。为此，提出一种支持完整性审计的透明安全去重方案。与以往工作相比，该设计通过一次性证明验证，可实现对文件所有者数量和完整性的验证。它还

榴莲遇见咖啡

1346人浏览 · 2023-12-19 22:47:04

榴莲遇见咖啡 · 2023-12-19 22:47:04 发布

Mingyang Song, Zhongyun Hua, Yifeng Zheng, Tao Xiang, and Xiaohua Jia, Fellow, IEEE

主要研究目的：

传统的安全去重方案要求用户使用特定的加密算法对外包文件进行加密，无法提供语义安全。用户也无法直接从去重中获益，因为实际存储成本与提供价格之间的关系仍然不透明。

因此，用户可能不愿意通过使用语义安全算法加密他们的数据来与云合作。此外，数据完整性是云存储用户关心的重要问题。为此，提出一种支持完整性审计的透明安全去重方案。与以往工作相比，该设计通过一次性证明验证，可实现对文件所有者数量和完整性的验证。它还保护了文件的私有内容和文件所有权的隐私不受恶意用户的侵害。此外，该方案还包括一种批量审计方法，可以同时验证多个文件所有者的数量和多个文件的完整性。

本文的贡献

提出了一种新的基于加密云存储的透明去重和完整性审计方案。该方案允许用户通过一次性的完整性证明验证同时验证文件的完整性和所有者的数量，可以显著降低用户的计算开销。此外，它还支持批量审计，允许用户同时验证多个文件的完整性和所有者编号。

我们的方案旨在抵抗OOPA和OP泄漏。这意味着恶意用户不能以离线方式获取文件的私有内容，并能很好地保护用户的OP不受未授权实体的攻击。

形式化地验证了方案的正确性并证明了其安全性。实验结果表明，我们的方案可以取得与其他先进方案相当的性能。

问题表述

系统模型

本文中系统模型有三种实体:CSP、user和区块链。

用户: 用户将加密后的文件上传到CSP存储。由于不同的用户可以上传相同的文件，所以所有的用户可以分为外包新文件的初始上传者和外包已有文件的后续上传者。CSP在每次审计周期结束时发布链上证明，用户可以验证文件所有者的数量和外包文件的完整性，其中周期表示两次连续审计之间的时间间隔。

CSP: CSP为用户提供存储服务。它执行安全的重复数据删除，为其存储的文件生成完整性证明，并在每次迭代结束时将证明发布到区块链上。

区块链: 区块链是一个具有各种节点的公共分布式账本系统。新的不可预测的块不断生成。它记录了CSP发布的校样结果。

威胁模型

用户: 用户可以使用公开的证明信息，在不与云端持续交互的情况下，以离线的方式启动OOPA获取其他用户的私有文件内容，窥探其他用户的OP。

CSP:由于硬件故障等实际原因，可能导致CSP数据丢失。为了维护其商业信誉，它可以通过伪造文件、认证标签和重签名密钥来欺骗用户。CSP还可能向用户提供虚假的文件所有者数量，以获取更多的经济利益。文章中假设用户和CSP之间的通信是通过安全的标准传输层安全(TLS)信道[42]进行的。

设计目标：

构造了一种新的支持完整性审计的加密数据透明去重方案，实现了以下设计目标。

•功能。透明去重和审计。它允许CSP对密文和认证标签进行去重，并允许用户检查其外包文件的完整性和文件所有者的数量。同时支持透明去重和完整性审计。

        安全。包括数据机密性、数据完整性、抗OOPA攻击和OP保护。
        信息。其他用户无法获知哪些文件属于一个用户，哪些文件属于同一个用户。
        效率。该方案通过批量审计，将完整性验证与数量验证相结合，显著降低了用户端的计算开销与现有的最先进方案相比，只使用一次性的完整性验证计算。

方案设计

系统设置：

CSP生成云用户的公共系统参数及其私钥的过程如下。

1）随机选择一个秘密参数 $k$ ，运行复合双线性参数生成器 $Gen(k)$ 生成一个元组 $(p, q, N, G_1, G_2, e)$ ，其中。

2) 随机选择一个生成器 $g \in G_1$ 和一个 $u \in G_1$ 元素 $u \in G_1$

3) 计算欧拉函数 $u \in G_1$ .

4) 随机选择一个值 $b( 1<b< \phi(N))$ .满足 $b$ 和 $\phi (N)$ 互素。

5) 求出 $d$ 满足 $d \times b \equiv 1 mod \phi(N)$

6) 随机选取一个值t∈[10,20]。

7)选择两个抗碰撞的哈希函数 $H_1: \left \{ 0,1 \right \}^*\rightarrow Z_N^*$ , $H_2: \left \{ 0,1 \right \}^*\rightarrow G_1$ 和一个伪随机函数 $\pi: \left \{ 1,2,\cdot \cdot \cdot ,n \right \}\times Z_N^*\rightarrow Z_N^*$ 。选择一个MLE键生成函数 $H_3:\left \{ 0,1 \right \}^*\rightarrow \left \{ 0,1 \right \}^l$ 。CSP向所有用户发布公共参数 $\left\{ b,N,g,u,l,t\right\}$ 和公共函数 $\left \{ H_1,H_2,H_3,e,\pi \right \}$ ，并保留秘钥 $d$ 。

每个用户 $U_a$ 随机选择 $\theta_a \in Z\ast N$ ，该值被用作批量审计重签名密钥生成的秘密值。

数据上传

与传统方案一样首先使用密文的哈希值进行密文去重。 $h=H_3(C)$ .但是直接使用哈希值 $h$ 做公开文件标签才审计阶段容易受到OOPA攻击。因此构造新的文件标签 $ID_F=H_1(H_1(C)^d \ mod \ N)$ ,加入了CSP的私钥 $d$ .这确保了公共文件标记不能由用户独立生成。因此，任何攻击者都无法离线计算可能的文件标签并将其与公开的文件标签进行比较以启动OOPA。此外，用户还需要将重签名密钥rk和批量审计重签名密钥bk上传到云端，并从云端获取每个外包文件的所有者索引ind。

给出了CSP的存储结构和存储集合以及用户Ua。密钥、所有者索引、每个文件的块数存储在用户 $U_a$ 的本地存储结构 $LS_a$ 中。用户 $U_a$ 上传的文件的标签被存储在一个集合 $OS_a$ 中，用户在每次迭代结束时对每个文件在 $OS_a$ 中的完整性和所有者数量进行检查。每个文件的所有者信息存储在CSP的存储结构 $DB_o$ 中，用户的重签名密钥存储在CSP的存储结构 $DB_k$ 中。

重复检测

1) 用户Ua想要将文件 $F = \left \{ m_i \right \}^ n_{i=1}$ 外包给CSP时，他/她首先与CSP进行交互，以检查该文件是否已经在云上存在，如下所示。•用户Ua首先为每一个块 $m_i (1 \leq i \leq n),$ 生成MLE密钥 $k_i=H_3(m_i)$ .然后加密所有的块得到密文 $C=\left \{ c_i \right \}_1^n$ $c_i=SE.Enc(k_i,m_i) (1\leq i\leq n)$ .

2) 用户Ua计算哈希值 $h=H_3(C)$ 发送给CSP。

3）CSP检查是否重复，如果文件存在，CSP发送 $DUP$ 给用户，否则，发送 $NoDup$ .

如果收到的反馈是 $NoDup$ ，用户就是初始上传者，执行后续上传操作，否则，就是后续上传者。

注意：由于与文件内容的机密性相比，云中的文件存在的重要性要小得多，因此客户端安全去重方案[，文中的引用11,13,37-39]将通信成本的节省优先于此特定的隐私信息。此外，透明去重方案文中引用为[25,26]允许用户知道和验证文件所有者的数量，使用户能够直接受益于存储节省。本文的方案遵循这一设计趋势，既实现了透明去重的特性，又节省了通信带宽。

初始上传

Ua只有收到 $NoDup$ 执行以下操作。

1）上传密文 $C=\left \{ c_i \right \}_1^n$ 到CSP。

2）CSP检查 $h\overset{\text{?}}{=}H_1(C)$ .如果成立，计算 $Z=h^d mod \ N$ 并将 $ind$ 设置为1.( 其中ind表示文件所有者的索引) 。注意：第 $ind^{th}$ 个用户负责审计和验证文件的第 $ind^{th}$ 次的审计证明。然后CSP将（ $Accept, z, ind$ ）给用户Ua。

3）如果用户Ua接收( $Accept, z, ind$ )，则执行如下操作。1)用户Ua检查 $z^b mod N \overset{\text{?}}{=}h$ ，如果验证通过，则计算出公共文件标签 $ID_F = H_1(z)$ 。2)用户Ua首先计算认证标签的签名密钥 $sk = H_1(F)$ ，然后随机选择 $s_a, x_a \in Z\ast N$ 作为重签名密钥 $rk^{(a)}_ F = (s_a, x_a)$ ，最后计算验证密钥 $vk^{(a)}_F = g^{sk\cdot sa}$ 和批量审计重签名密钥 $bk^{(a)}_F = \theta _a \cdot sk^{-1}$ 。用户Ua添加 $(ID_F,vk^{(a)}_ F, rk _F^{(a)},ind,n)$ 到他/她的本地密钥存储结构 $LS_a$ 并添加 $ID_F$ 到集合 $OS_a$ , $LS_a$ 收收集用户Ua上传的每个文件的验证密钥、重签名密钥和所有者索引， $OS_a$ 收集用户Ua上传的每个文件的标签。3)为每一个密文块 $c_i (1\leq i\leq n)$ ,用户Ua将其划分为长度相等的s个扇区，然后使用 $sk$ 对 $c_i$ 进行签名，生成如下公共身份验证标签。 $\sigma_i=[H_2(ID_F||i) \cdot \prod \limits_{j=0}^s u ^{c_{i,j}}]^{sk},(1\leq i\leq n)$ .

用户Ua将 $ID_F, \left\{\sigma \right\}_{i=1}^n,rk_F^{(a) }$ 上传到CSP。

4）收到用户上传的数据后， CSP首先验证 $ID_F \overset{\text{?}}{=}H1(H1(C)^d mod N)$ ,如果成立 CSP添加（ $ID_F, U_a,rk_F^{(a)},bk_F^{(a)}$ ）到他的 $DB_k$ 中,并且将 $ID_F,U_a,ind$ 加入到 $DB_O$ 。 $DB_k$ 存储用户的重签名密钥， $DB_O$ 存储每个文件的所有者信息。对于{ $c_i (1\leq i\leq n)$ 和 $\left\{\sigma \right\}_{i=1}^n$ ，它们被直接存储。如果验证失败，CSP会拒绝存储请求，因为上传的密文与公开文件标签不匹配。

后续上传

Ua收到CSP的 $Dup$ 后，执行如下的后续上传操作。

1）用户Ua选择一个随机的位串 $\xi \in \left\{0,1 \right \}^l$ 并把它发送给CSP.

2)当接收到 $\xi$ 时，CSP首先选择一个随机比特串 $\gamma \in \left\{0,1\right\}^l$ ,并计算 $\beta = H_2(\gamma||\xi||C)$ ，然后将( $\gamma ,\beta$ )发送回用户Ua.

3)当用户Ua接收到( $\gamma ,\beta$ )时，验证 $\beta \overset{\text{?}}{=} H_2(\gamma ||\xi ||C)$ 。如果验证通过，用户Ua计算 $\beta^* \overset{\text{?}}{=} H_2(\xi ||\gamma ||C)$ ，并将 $\beta^*$ 发送到CSP

4)当接收到 $\beta^*$ 时，CSP验证 $\beta^* \overset{\text{?}}{=} H_2(\xi ||\gamma ||C)$ 。如果验证通过，则CSP向用户Ua发送(A $ccept, z, ind$ )，其中 $ind = max(DB_o^{}ind) [IDF]) + 1$ 和 $max(DB^{(ind) }_o [IDF])$ 表示当前文件 $F$ 拥有者的数量。否则，CSP向用户Ua发送Reject，并完成交互。

5）用户Ua收到( $Accept, z, ind$ )，信息后，进行如下操作。1)用户Ua检查 $z ^b mod N = h$ ，如果验证通过，则计算公共文件标签 $ID_F = H_1(z)$ 。2)用户Ua选择 $s_a, x_a \in Z\ast N$ 作为重签名密钥 $rk^{(a)}_ F = (s_a, x_a)$ ，并计算出签名密钥 $sk = H_1(F)$ 、验证密钥 $vk^{(a)}_ F = g ^{sk\cdot sa}$ 和批量审计重签名密钥 $bk^{(a)}_ F =\theta _a \cdot sk^{-1}$ 。用户Ua将 $(ID_F, vk^{(a)}_ F, rk^{(a) }_F, ind, n)$ 加入到本地密钥存储结构 $LS_a$ 中，并将 $ID_F$ 加入到集合 $OS_a$ 中。3)用户Ua发送 $(ID_F, rk^{(a)}_ F, bk^{(a) }_F,)$ 给CSP。

6)CSP验证 $ID_F \overset{\text{?}}{=} H_1(H_1(C) ^d mod N)$ 。如果验证通过，则CSP将Ua视为文件 $F$ 的实际所有者，然后将( $(ID_F, U_a,rk^{(a)}_ F, bk^{(a) }_F,)$ 添加到自己的数据库 $DB_k$ 中，将 $(ID_F, U_a, ind)$ 添加到自己的数据库 $DB_o$ 中。否则，CSP拒绝存储请求。

所有者编号和完整性验证

该方案允许用户通过一次性的完整性证明验证来验证文件所有者的数量和文件的完整性。在每个审计周期结束时执行验证。因此，CSP需要在每次迭代结束时在区块链上发布证明，用户可以使用这些链上证明来检查每个文件的所有者号和完整性。为实现认证标签去重，文件所有者使用相同的消息相关密钥生成初始认证标签。然后在证明生成过程中使用代理重签名技术来同时验证文件所有者数量和完整性。该技术允许CSP充当代理，将初始认证标记转换为与用户相关的认证标记，并使用与用户相关的私钥对其进行签名。这种转换确保每个完整性证明只能通过特定用户的验证，并确保CSP向文件F的每个所有者Ua提供不同的用户相关的完整性证明 $(\delta ^{(a) }_F,\psi ^{(a)}_F)$ 。审计设计中，CSP需要在同一套psf中发布文件F的所有完整性证明。这组证明的数量表示所有者的数量。为了使用户能够接受报告的文件属主数量，CSP必须为每个属主发布用户相关的证明，并成功通过每个属主的完整性验证。该设计通过审计实现了对文件所有者数量的验证和完整性验证(emmmm看到这里有点崩溃了，这么复杂)。

生成证明

对于存储在云上的每个文件 $F$ , CSP为用户生成证明，验证文件的完整性和文件所有者的数量。在为所有文件所有者生成完整性证明之前，CSP从区块链中获取最新生成的 $t$ 个块的哈希值 $\left\{sh_i\right\} ^t_{i =1}$ ，并计算出 $b_h = H_1(sh_1||sh_2||\cdot \cdot \cdot||sh_t)$ 。然后CSP生成如下证明

其中 $rk_F^{(a)}=(s_a,x_a)$ 是用户Ua在上传数据过程中上传的。

计算所有所有者的证明后，CSP在区块链上发布( $ID_F, PS_F$ )。

证明验证

用户Ua首先从区块链中获取最新生成的 $t$ 个块的哈希值 $\left\{sh_i\right\} ^t_ {i=1}$ 并进行计算 $bh = H_1(sh_1||sh_2||\cdot \cdot \cdot ||sh_t).$ 然后执行：

$ind$ 是由CSP在Ua上传数据过程中分配的，并表明用户负责检索和验证文件的第 $ind^{th}$ 个证明

如果验证无效或区块链上不存在第 $ind^{th}$ 个证明，则用户Ua知道文件所有者的数量不正确，文件已损坏。

批量审核

提供了一种批量审计的方法来提高用户端的验证效率。所有者利用明文或密文的哈希值生成相同的签名密钥，为相同的文件生成共同的初始认证标签，实现认证标签去重。然而，对于多个文件，认证标签的签名密钥是不同的，这给重删云存储中的批量审计带来了挑战。为了解决这个问题，采用代理重签名技术，将CSP指定为代理。CSP对多个文件的初始认证标签进行重新签名，获得使用相同用户关联私钥签名的新认证标签。这可以实现批量审计。

为了确保文件所有者数量的透明性，我们采用了与一般审计类似的策略。区别在于，CSP将证明集中 $PS$ 中为用户Ua提供的每个单独证明替换为一个聚合证明。这个聚合证明代表了Ua拥有的所有文件相关联的证明的聚合。在验证过程中，用户只需检查提供给他的不同文件的证明是否相同。然后，用户验证聚合证明

批量审计的证明生成

在生成完整性证明之前，CSP从区块链中获取最新生成的 $t$ 个块的哈希值 $\left\{sh_i\right\} ^t_{i =1}$ ，并计算出 $b_h = H_1(sh_1||sh_2||\cdot \cdot \cdot||sh_t)$ 。然后CSP生成如下证明。 $rk_F^{(a)},bk_F^{(a)}$ 是用户Ua在上传数据过程中上传的。

批处理审核的证明验证

用户Ua首先从区块链中获取最新生成的 $t$ 个块的哈希值 $\left\{sh_i\right\} ^t_ {i=1}$ 并进行计算 $bh = H_1(sh_1||sh_2||\cdot \cdot \cdot ||sh_t).$ 然后执行.

数据恢复

用户Ua下载文件时，首先向CSP发送下载请求，文件标签为 $ID_F$ 。CSP通过检查 $DB_o[ID_F, U_a]$ 是否存在来验证用户Ua是否为文件的属主。如果存在，则CSP允许用户Ua下载该文件。否则，CSP拒绝下载请求。用户Ua下载密文 $\left\{c_i\right\} ^n_{i=1}$ 后，解密密文 $\left\{c_i\right\} ^n_{i=1}$ ，得到的明文文件为. $m_i = SE.Dec(k_i, c_i)(1 \leq i \leq n)$ .

note：本文确实十分的复杂，本来以为区块链是主要技术，但是只用了性质。这也是写论文的一种套路吧，后面正确性验证，在草稿纸上证明的，不再赘述。本文确实有很多看似冗余的操作，值得仔细阅读。

穷举字典攻击：是一种常见的内部攻击。其威胁源于CE的确定性。

OOPA介绍实例：

假设Alice将她的工资合同文件外包给CSP，而CSP的另一个用户Bob拥有合同的模板文件。为了获得Alice的工资信息，Bob可以生成Alice合约的多个版本，其中包含Alice的名字和不同可能的工资。然后Bob加密这些文件并计算密文的哈希值。使用public file标签，Bob可以知道云中存储的是哪个版本，然后获取Alice的工资。