Page 440 - 《软件学报》2026年第2期
P. 440

张源 等: 以用户为中心的云辅助跨应用数据安全流转                                                        919


                 结构和内容. 在跨     App  数据统一托管于云服务器的条件下, 若单纯采用               PIR  进行数据检索, 可能导致云服务器能
                 够访问所有用户数据, 从而破坏用户侧的隐私保障. 相比之下, 可搜索加密技术为以用户为中心的数据管理提供了
                 更加契合的安全框架       [20] . 其基本思想是在用户本地对数据进行加密后外包存储至云服务器, 随后授权用户凭借密
                 钥为查询关键词生成陷门; 陷门不会泄露关键词内容, 而云服务器仅依据陷门执行检索并返回包含该关键词的密
                 文文件. 服务器除了知道某个密文文件是否匹配关键词外, 无法获得额外信息. 用户最终通过解密密文恢复查询结
                 果  [21] . 这种模式能够同时保证数据的可用性与保密性, 使用户能够在不暴露数据内容和检索意图的前提下实施高
                 效查询, 因此在跨     App  数据流转场景中比     PSI 与  PIR  方案更具优势. 本研究亦采用可搜索加密作为核心技术路径.
                    可搜索加密的发展始于         Song  等人  [20] 的  SWP  方案, 其基于逐词扫描的方式在不可信服务器上实现安全搜索.
                 尽管  SWP  可确保服务器无法获取多余信息, 但其线性扫描过程使得时间开销随文件规模增大而显著增加, 并因泄
                 露关键词位置而无法抵御统计分析攻击. 随后, Goh             [41] 在  2003  年提出基于布隆过滤器的    Z-IDX  方案, 而  Chang  等
                 人  [42] 在  2005  年构建了可抵御统计攻击的    PPSED  方案, 但两者均未显著改善效率问题. Curtmola 等人         [43] 在  2006
                 年首次系统化提出对称可搜索加密            (symmetric searchable encryption, SSE) 的安全定义, 并给出适用于非自适应与
                 自适应攻击模型的       SSE-1  与  SSE-2  方案. 围绕提升  SSE  在复杂场景下的性能与安全性问题, 后续研究者陆续提出
                 多种改进的    SSE  方案  [44−46] .
                    在不可信服务器的路由环境下, Boneh          等人  [47]  率先提出了非对称可搜索加密的概念, 并基于            BF-IBE  构建了
                 首个  PEKS  方案  BDOP-PEKS [48] . 在该机制中, 数据拥有者利用接收者的公钥加密数据及关键词, 接收者凭私钥生
                 成搜索令牌, 服务器据此判断密文是否与令牌匹配. PEKS                常应用于云邮件等存储-转发系统, 其效率低于               SSE  但
                 具有更强的可扩展性.
                    然而, Byun  等人  [22] 的研究表明, 真实关键词的明文空间较小且用户习惯使用有限词汇, 导致                   PEKS  易受离线
                 KGA  攻击. 为抵御   KGA, 研究者提出了多类具有不同安全特性的              PEKS  方案  [49−54] . 现有方案可以分为  4  类: (1) 依
                 赖可信检测方完成密文与令牌匹配            [49] , 能够阻止外部攻击者执行     KGA, 但无法抵御半诚实服务器; (2) 引入新型密
                 码学原语, 如不可区分混淆器, 使服务器无法伪造密文进行测试                   [50] , 但混淆器的效率问题限制其实用性; (3) 采用模
                 糊关键词检索, 使服务器难以精确获得关键词                [51] , 但安全性仍有限且增加用户端负担; (4) 使用服务器协助的
                 PEKS  方案  [53] , 引入可信密钥服务器帮助用户生成密文与检索令牌. 与前述方案相比, 服务器协助的                     PEKS  方案在
                 安全性与效率间取得更符合实际需求的平衡. 其构建思路源于                     Bellare 等人  [54] 提出的  Dupless 框架, 尽管  Dupless
                 未被直接应用于      PEKS. 2016  年, Chen  等人  [53] 构建了首个单服务器协助的   PEKS  方案, 但其假设密钥服务器长期
                 可靠, 因而存在单点失效问题. 2019        年, Zhang  等人  [6] 提出多服务器协助的   PEKS  机制, 引入分布式密钥服务器及
                 更新机制, 有效缓解      KGA  与单点失效风险, 但未关注适用于移动环境的便携高效的用户身份认证需求. 本文提出
                 的方案   CADC  使用多  App  协助的门限口令加固机制以及长短效秘密结合的便捷的身份认证机制, 在保证云辅助
                 下数据跨   App  流转过程中能够有效抵御离线          KGA  攻击和单点失效问题的基础上, 进一步实现了适用于移动用户
                 且便携高效的安全认证机制, 支撑数据跨             App  可信流转.

                  2   问题描述

                  2.1   系统模型
                    CADC  共包含   3  个实体, 分别是用户、一组      App  和云存储服务器, CADC     的系统模型如图      1  所示.
                    1) 用户: 用户拥有一个设备、一个不可复用的长效口令和用户名, 用户有一组需要使用的                          App. 在身份认证阶
                 段, 用户需要在    App  的协助下加固长效口令, 完成注册. 随后, 用户使用加固后的长效口令申请一个认证证书授权
                 设备, 通过已授权设备, 用户可以在         App  和云存储服务器进行高效的登录和使用. 在数据请求阶段, 用户分别与作
                 为密钥服务器的      App  进行交互, 在各   App  的协助下强化关键词, 计算陷门以完成数据检索, 解密相应数据文件的
                 密文后, 用户可以将其中允许共享的数据发送给请求数据的                   App.
                    2) App: CADC  涉及一组  App  {A 1 ,A 2 ,...,A n }. 它们既作为身份服务器也作为密钥服务器, 一方面, App    分别与
                 用户交互, 协助用户加固长效口令, 通过检查用户是否拥有正确的长效口令来验证其身份. 另一方面, App                              分别与
   435   436   437   438   439   440   441   442   443   444   445