Page 389 - 《软件学报》2025年第7期

3310 软件学报 2025 年第 36 卷第 7 期

如果不存在任何概率多项式时间的攻击者能以不可忽略的优势赢得上述游戏, 则 q–1 假设成立.

3 形式化定义及设计目标

3.1 系统架构
如图 1 所示, 本文提出的支持高效数据所有权共享的动态云存储审计方案由数据拥有者 (data owner, DO)、
数据用户 (data user, DU)、云服务器 (cloud server, CS)、可信中心 (trusted authority, TA) 这 4 个实体组成.

4. 上传密文 9. 访问数据
云服务器
6. 13. 7.
发 数 提
11. 起 据 供
更数据拥有者 挑 更 证 数据用户
新 8. 战 新 明
数 验 5. 发起完整性审计
据 证 10. 申请所有权共享
审 证 12. 申请数据修改
计 明
密 1. 公开系统公共参数 3. 分发数据访问密钥
钥 2. 发送数据审计密钥 可信中心
图 1 系统架构图

● 数据拥有者需要将自己存储在 CS 中的数据与他人共享. 出于安全性考虑, DO 在上传数据之前会使用属性
基加密算法对数据进行加密. 此外, 本文方案还结合了变色龙哈希函数实现了数据的动态修改和数据所有权共享.
DO 可以通过 TA 向 CS 发起数据完整性验证来随时检查自己存储在 CS 中数据的完整性. 在本文方案中, DO 是
可信的.
● 数据用户可以访问 DO 共享的数据. 本文方案基于属性基加密实现了数据的细粒度共享, 只要 DU 自身拥
有的属性集合可以满足密文中的访问策略, DU 即可完成解密. 如果 DO 将数据的所有权共享给 DU, 则对于该数
据, DU 将拥有和 DO 相同的权限 (数据完整性验证和数据动态修改). 在本文方案中, DU 是半可信的.
● 云服务器拥有丰富的计算和存储资源, 主要负责存储 DO 上传的加密数据. 由于对 DO 来说, CS 是半可信
的机构, 可能会为了其自身利益欺骗 DO, 因此 CS 需要在收到完整性验证挑战时生成一个数据完整性的证明. 在
本文方案中, CS 是半可信的.
● 可信中心负责生成系统公共参数、为 DU 生成密钥以及协助 DO 对其存储在 CS 中的数据进行完整性验
证. 在完整性验证的过程中, TA 首先向云服务器发送一个审计挑战, 通过验证 CS 对于该挑战的证明, TA 可以判
断 CS 保存的数据是否完好. 在本文方案中, TA 是可信的.
3.2 算法定义
本文提出的支持高效数据所有权共享的动态云存储审计方案主要包括 9 个算法, 分别是 Setup、KeyGen、
Upload、Chall、Proof、Verify、Access、Share 以及 Update, 具体定义如下.
λ
(1) Setup(1 )→{pp, msk}: 系统建立算法, 算法输入安全参数 λ, 输出系统公共参数 pp 和系统主私钥 msk.
(2) KeyGen(pp, msk, S, uid)→{sk 1 , sk 2 }: 密钥生成算法, 算法输入系统公共参数 pp、系统主私钥 msk、属性集
合 S 以及用户身份 uid, 输出数据访问密钥 sk 1 以及数据审计密钥 sk 2 .
(3) Upload(pp, ck, (M, ρ), sk 2 , F)→CT: 数据上传算法, 算法输入系统公共参数 pp、对称密钥 ck、访问策略
(M, ρ)、数据审计密钥 sk 2 、数据文件 F, 输出密文 CT.
(4) Chall(sk 2 )→chal or ⊥: 挑战算法, 算法输入数据审计密钥 sk 2 , TA 首先验证用户是否具有该数据的所有权,
如果验证通过, 算法输出挑战 chal, 否则算法输出⊥.
(5) Proof(CT, chal)→{P, tag}: 证明算法, 算法输入密文 CT 和挑战 chal, 输出一个证明 P 以及文件标签 tag.