HTML
-
文献[4]方案在文献[2-3]的基础上,添加了密文类型的修改功能。在密文类型修改阶段中DO可以生成用于修改密文类型的密钥,并将其发送给storage; 根据接收到的密钥,storage可以修改密文类型的信息,并生成新的预共享密文。在经过密文共享阶段的重加密后再生成共享密文,最终实现数据的安全共享。仔细分析整个工作流程,在添加了密文类型修改阶段后,该方案直接使用了原来的密文共享步骤,并没有在后面重加密和解密步骤对修改后的密文类型的状态做出相应的验证。整个方案的完整性遭到了破坏。
由于类型修改缺乏验证,攻击者可以随意修改密文类型标记t'。将修改后t'代入后面的代理重加密过程和解密过程。如下面推导过程所示是否被修改,与这两个过程是否正确执行并不相关。相应的服务器、数据持有者、数据共享对象也无法及时地发现密文类型是否被攻击者所修改。
1)攻击者截获算法8)[4]中,由数据拥有者执行算法TKey (t, t'SKIDi)生成的并传送于云存储服务器的修改密文类型密钥,有:
将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处获取到在密文类型为t1情况下的密文:${c_{{m_1}}} = ({c_{1, {m_1}}}, {c_{2, {m_1}}}, {c_{3, {m_1}}})$,其攻击目标为恢复相应的明文m1。攻击者与云服务器合谋攻击步骤如下。
首先攻击者采用选择明文攻击,获取到密文类型为t2情况下的明密文对为:
式中,${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所示。
t1 t2 … tn t1 t1→t1 t1→tn t2 t2→t2 t2→tn $ \vdots $ $ \ddots $ tn tn→tn 在表中除自身的转换外,每一项都对应了一次密文类型转换。这些项代表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'}}$。如果密文类型转换记录表中存在一个t1与t2共同指向的密文类型t*,将由t1转换到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最终可以通过计算得到由类型t1到共同类型t*的密文类型转换密钥${\rm{RT}}{{\rm{K}}_{{t_1} \to {t^ * }}}$。再经过算法9)[4]进行密文类型转换为:
得到新类型t*下的预共享密文${c'^ * }_{2, {m_1}}$,同理可得由t2转换到t*情况下的预共享密文${c'^ * }_{2, {m_2}}$为:
接下来在代理重加密过程中,服务器根据记录的代理重加密密钥为:
修改有:
令$c_{\rm{2}}^ * = {c'^ * }_{2, {m_1}}{c'^ * }_{2, {m_2}}$,攻击者最终将得到篡改过的共享密文为:
其中,有:
攻击者最终通过合法解密过程7)[4]得到:
由m可得${m_1} = m/{m_2}$
攻击者攻击成功,由上可见在一定条件下,即攻击者与云服务器合谋时,密文类型修改会引起新的选择明文攻击问题。