云存储中，代理重加密(PRE)^[1]技术可以保障用户数据在存储第三方的安全性和可共享性。该技术的核心思想是：数据拥有者以密文形式将数据存储在第三方；数据拥有者可以委托存储第三方对其存储的密文进行重加密并共享给其他用户。

针对现实应用，基于文献[2-3]的类型和身份的代理重加密方案，文献[4]提出了一种类型可修改的基于身份代理重加密方案^[5-8]。该方案不但实现PRE中细粒度的密文共享，还解决了原方案密文类型信息静态，不能动态修改问题。文献[4]发现了密文类型信息动态修改的现实意义与应用场景。如数据拥有者(data owner, DO)为节省本地存储开销，或方便数据在不同终端的灵活使用，将标记为“不可共享”类型的加密数据存储于storage。DO根据现实需要希望将“不可共享”类型修改为“可共享”类型；一段时间后又需要将“可共享”类型恢复为“可共享”。类型信息的动态修改就可以很好的适应此类应用。

文献[4]虽然具有很高的现实应用价值，并且根据其安全性分析可知具有与文献[2]相同的安全性。但是在对其所提方案进行仔细研究后发现，在完成密文类型信息的修改后并没有对密文类型信息进行验证，如图 1所示。其方案存在两个安全漏洞：1)类型修改缺乏验证，攻击者可以随意修改类型标记，而不会被接收方发现。2)由于类型修改引起了新的条件性选择明文攻击问题。图中实例所涉及的通信实体与文献[4]保持一致。DO、数据共享者(receiver, R)、密钥生成中心(KGC)、第三方存储器(storage)。

图  1  文献[4]的方案基本工作流程

文献[4]方案在文献[2-3]的基础上，添加了密文类型的修改功能。在密文类型修改阶段中DO可以生成用于修改密文类型的密钥，并将其发送给storage; 根据接收到的密钥，storage可以修改密文类型的信息，并生成新的预共享密文。在经过密文共享阶段的重加密后再生成共享密文，最终实现数据的安全共享。仔细分析整个工作流程，在添加了密文类型修改阶段后，该方案直接使用了原来的密文共享步骤，并没有在后面重加密和解密步骤对修改后的密文类型的状态做出相应的验证。整个方案的完整性遭到了破坏。

由于类型修改缺乏验证，攻击者可以随意修改密文类型标记t'。将修改后t'代入后面的代理重加密过程和解密过程。如下面推导过程所示是否被修改，与这两个过程是否正确执行并不相关。相应的服务器、数据持有者、数据共享对象也无法及时地发现密文类型是否被攻击者所修改。

1)攻击者截获算法8)^[4]中，由数据拥有者执行算法TKey (t, t'SK_IDi)生成的并传送于云存储服务器的修改密文类型密钥，有：

将t'修改成t"后传于云存储服务器。

2)云存储服务器执行算法9)^[4]中的TSet (c, TK)算法为：

3)云存储服务器在收到具有新的密文类型的密文$c' = ({c'_1}, {c'_2}, {c'_3})$。其数据的代理重加密过程和解密过程与正常情况一致。由数据拥有者执行算法5)^[4]的RKey ()算法为：

攻击者截获后，仍将t′修改成t"后传于云存储服务器为：

4)云存储服务器执行算法6)^[4]中的REnc$(c, {\rm{R}}{{\rm{K}}_{{\rm{I}}{{\rm{D}}_i} \to {\rm{I}}{{\rm{D}}_j}}})$算法，得到$c' = ({c'_1}, {c'_2}, {c'_3}, {c'_4})$；${c'_2} = {c_2} \times \hat e({c_1}, {\rm{SK}}_{{\rm{I}}{{\rm{D}}_i}}^{ - {H_2}({\rm{S}}{{\rm{K}}_{{\rm{I}}{{\rm{D}}_i}}}, \;t')}{H_1}(X)) = m\hat e({g^r}, {H_1}(X))$；${c'_1} = {c_1}$；${c'_3} = {g^{r'}}$；${c'_4} = X\hat e{({H_1}({\rm{I}}{{\rm{D}}_j}), {\rm{Pub}})^{r'}}$。

5) R执行算法7)^[4]的${\rm{RDec}}(c', {\rm{S}}{{\rm{K}}_{{\rm{I}}{{\rm{D}}_j}}})$算法，解密得到明文m:$X = \frac{{{{c'}_4}}}{{\hat e({{c'}_3}, {\rm{S}}{{\rm{K}}_{{\rm{I}}{{\rm{D}}_j}}})}}$；$m = \frac{{{{c'}_2}}}{{\hat e({{c'}_1}, {H_1}(X))}}$。

根据上面的推导，可以清晰地看到由于重加密过程与解密过程不涉及密文类型标识t'，因此可任意修改。攻击者只需要针对密文类型修改密钥和代理重加密密钥的传输过程做出相应的篡改，就可以将原本的可共享类型修改为不可共享类型，将不可共享类型修改为可共享类型。

在文献[4]中出现的PRE方案“即使storage不可信，storage也无法知道数据的内容”。但是该方案在提供数据类型可修改功能的过程中，实际上泄露了部分的数据信息内容，造成了新的选择明文攻击问题。

攻击者与服务器合谋，攻击者在storage处获取到在密文类型为t₁情况下的密文：${c_{{m_1}}} = ({c_{1, {m_1}}}, {c_{2, {m_1}}}, {c_{3, {m_1}}})$，其攻击目标为恢复相应的明文m₁。攻击者与云服务器合谋攻击步骤如下。

首先攻击者采用选择明文攻击，获取到密文类型为t₂情况下的明密文对为：

式中，${c_{2, {m_2}}} = {m_2}\hat e{({H_1}({\rm{I}}{{\rm{D}}_i}), {\rm{Pub}})^{{r_2}{H_2}({\rm{S}}{{\rm{K}}_{{\rm{I}}{{\rm{D}}_i}}}, \;{t_{\rm{2}}})}}$。

根据前面得到的密文${c_{{m_1}}} = ({c_{1, {m_1}}}, {c_{2, {m_1}}}, {c_{3, {m_1}}})$，${c_{2, {m_1}}} = {m_1}\hat e{({H_1}({\rm{I}}{{\rm{D}}_i}), {\rm{Pub}})^{{r_1}{H_2}({\rm{S}}{{\rm{K}}_{{\rm{I}}{{\rm{D}}_i}}}, \;{t_{\rm{1}}})}}$，则有：

从上面可以看出，如果密文类型不可修改，该方案是可以抵御选择明文攻击的。但是由于数据类型明文存放、传输并可修改，带来了新的问题。如果云服务器出于好奇，将历史的代理重加密密钥与密文类型转换密钥记录，其中密文类型转换记录如表 1所示。

在表中除自身的转换外，每一项都对应了一次密文类型转换。这些项代表storage记录了相应的密文类型转换所需的密文类型转换密钥。分析算法8)^[4]密文类型转换密钥${\rm{TK}} = (t', {\rm{SK}}_{{\rm{I}}{{\rm{D}}_i}}^{ - {H_2}({\rm{S}}{{\rm{K}}_{{\rm{I}}{{\rm{D}}_i}}}, \;t)}{\rm{SK}}_{{\rm{I}}{{\rm{D}}_i}}^{{H_2}({\rm{S}}{{\rm{K}}_{{\rm{I}}{{\rm{D}}_i}}}, \;t')})$得知，其数据结构只与$({\rm{S}}{{\rm{K}}_{{\rm{I}}{{\rm{D}}_i}}}, t', t)$相关。这说明storage对密文类型转换的操作是可以多次叠加的。将TK=()中的密文类型转换密钥${\rm{S}}{{\rm{K}}_{{\rm{I}}{{\rm{D}}_i}}}^{ - {H_2}({\rm{S}}{{\rm{K}}_{{\rm{I}}{{\rm{D}}_i}}}, \;t)} \times {\rm{S}}{{\rm{K}}_{{\rm{I}}{{\rm{D}}_i}}}^{{H_2}({\rm{S}}{{\rm{K}}_{{\rm{I}}{{\rm{D}}_i}}}, \;t')}$记做${\rm{RT}}{{\rm{K}}_{t \to t'}}$。如果密文类型转换记录表中存在一个t₁与t₂共同指向的密文类型t^*，将由t₁转换到t^*中间所经历的密文类型记录为一个非空集合$\{ {t_{{\theta _1}}}, {t_{{\theta _2}}}, \cdots, {t_{{\theta _l}}}\} $，$1 \le l \le n$。storage可以通过查询记录表获取所需的密文类型修改密钥组：$\{ {\rm{RT}}{{\rm{K}}_{{t_1} \to {t_{{\theta _1}}}}}, {\rm{RT}}{{\rm{K}}_{{t_{{\theta _1}}} \to {t_{{\theta _2}}}}}, \cdots, {\rm{RT}}{{\rm{K}}_{{t_{{\theta _l}}} \to {t_{{i^ * }}}}}\} $。对密文类型修改密钥进行乘积处理，有：

storage最终可以通过计算得到由类型t¹到共同类型t^*的密文类型转换密钥${\rm{RT}}{{\rm{K}}_{{t_1} \to {t^ * }}}$。再经过算法9)^[4]进行密文类型转换为：

得到新类型t^*下的预共享密文${c'^ * }_{2, {m_1}}$，同理可得由t₂转换到t^*情况下的预共享密文${c'^ * }_{2, {m_2}}$为：

接下来在代理重加密过程中，服务器根据记录的代理重加密密钥为：

修改有：

令$c_{\rm{2}}^ * = {c'^ * }_{2, {m_1}}{c'^ * }_{2, {m_2}}$，攻击者最终将得到篡改过的共享密文为：

其中，有：

攻击者最终通过合法解密过程7)^[4]得到：

由m可得${m_1} = m/{m_2}$

攻击者攻击成功，由上可见在一定条件下，即攻击者与云服务器合谋时，密文类型修改会引起新的选择明文攻击问题。

针对上述两个安全漏洞，本文对文献[4]的方案做出了以下改进：1)增加一个对类型t的完整性验证环节；2)对数据块进行编号排序。

在密文存储阶段，本文引入对数据块进行区分的编号信息$k\left( {{m_1}, \cdots, {m_k}, \cdots, {m_n} \in G, 1 \le k \le n} \right)$，并将算法3)^[4]修改为，${\rm{Enc}}({\rm{PK}}, {\rm{ID}}, {\rm{S}}{{\rm{K}}_{{\rm{ID}}}}, t, {m_k}, k)$其中，c₂由${c_2} = m\hat e{({H_1}({\rm{ID}}), {\rm{Pub}})^{r{H_2}({\rm{S}}{{\rm{K}}_{{\rm{ID}}}}, \;t)}}$改为${c_2} = {m_k} \times \hat e{({H_1}({\rm{ID}}), {\rm{Pub}})^{r{H_2}({\rm{S}}{{\rm{K}}_{{\rm{ID}}}}, \;t, k)}}$。

相应将算法4)^[4]修改为：

将算法5)^[4]修改为${\rm{RKey}}({\rm{I}}{{\rm{D}}_i}, {\rm{I}}{{\rm{D}}_j}, t, k, {\rm{S}}{{\rm{K}}_{{\rm{I}}{{\rm{D}}_i}}})$，其中有：

算法6)^[4]中storage将传输$c' = ({c'_1}, {c'_2}, {c'_3}, {c'_4}, {c'_5})$，其中有：

算法7)^[4]为：

算法8)^[4]为：

算法9)^[4]为：

通过上述改进，可以看到R可正常解密共享密文，最终取得m_k。

1) storage存储：

2) DO解密正确性：

3) storage存储预共享密文通过代理重加密后转换成最终共享密文：

4) R进行最后的数据解密：

文献[4]方案安全漏洞的产生是由于只添加了密文类型修改功能，而没有在其后的环节做出相应的验证，使方案整体的完整性遭到了破坏。针对密文类型修改所引起的两个安全漏洞，本文在其方案相应的位置做出了修改，下面通过对比来进行说明此修改是否会引起问题。

首先在密文存储阶段引入了对数据块进行区分的编号信息k，并将c₂由${c_2} = m\hat e{({H_1}({\rm{ID}}), {\rm{Pub}})^{r{H_2}({\rm{S}}{{\rm{K}}_{{\rm{ID}}}}, \;t)}}$改为${c_2} = {m_k}\hat e{({H_1}({\rm{ID}}), {\rm{Pub}})^{r{H_2}({\rm{S}}{{\rm{K}}_{{\rm{ID}}}}, \;t, k)}}$。这样就对数据的密文与数据的编号信息进行了位置绑定，阻止了可能的指数项合并。在遭遇攻击时，云服务器无法将不同编号数据块所对应的预共享密文顺利的改变为相同的类型结构，从而抵御了选择明文攻击。

其次为解决密文类型修改的验证问题，本文在代理重加密阶段将RKey ()中的${\rm{R}}{{\rm{K}}_{{\rm{I}}{{\rm{D}}_i} \to {\rm{I}}{{\rm{D}}_j}}}$由$(t, {\rm{SK}}_{{\rm{I}}{{\rm{D}}_i}}^{ - {H_2}({\rm{S}}{{\rm{K}}_{{\rm{I}}{{\rm{D}}_i}}}, \;t)}{H_1}(X), {g^{r'}}, X\hat e{({H_1}({\rm{I}}{{\rm{D}}_j}), {\rm{Pub}})^{r'}})$变为$(t, {\rm{SK}}_{{\rm{I}}{{\rm{D}}_i}}^{ - {H_2}({\rm{S}}{{\rm{K}}_{{\rm{I}}{{\rm{D}}_i}}}, \;t, k)}{H_1}{(X)^t}, {g^{r'}}, X\hat e({H_1}({\rm{I}}{{\rm{D}}_j}), $。

显然由于RKey ()是由DO进行运算的，在的H₁(X)指数部分增加t，并不会损害方案的安全性，但是却可以在算法7)^[4]的解密阶段与进行验证，如果${c'_5}$被修改，则R无法正确解密获取数据信息。

根据文献[2]的安全性证明与文献[4]的安全性分析。本文的方案对比文献[4]方案只增加了密文与数据块明文编号信息的绑定，以及最后一阶段对明文传输密文类型信息t的验证，因此本文的方案具有与文献[2]一致的安全性。

本文针对文献[4]方案中两个安全漏洞进行了分析与改进，并在其基础上提出了对类型可修改的基于身份代理重加密方案的改进方案。在经过对该方案的正确性验证与安全性分析后表明，该方案与传统的基于类型和身份的代理重加密方案相比，具有相同的安全性。