对称可搜索加密（SSE）基本原理与模型

讲密文检索，绕不开对称可搜索加密（Symmetric Searchable Encryption，简称 SSE）。为什么？因为它是这个领域最基础、最成熟的技术路线。我刚开始接触 SSE 时，第一反应是“这不就是把关键词加密了再做匹配吗？”——后来才发现，事情远没那么简单。

从一个小故事说起

2013 年我参与过一个医疗数据共享项目。医院想把患者病历存到云端，又怕泄露隐私。传统做法是先解密再搜索，但云服务商不可信。客户问：“能不能直接搜加密数据？”当时 SSE 还只在里比较火，我硬着头皮基于 Song-Wagner-Perrig 方案做了个原型。结果性能惨不忍睹——扫描 10 万条记录花了将近 2 分钟。嗯，这就是最原始的 SSE。

SSE 要解决什么问题？

说白了，就是让服务器在 不解密 的情况下，判断密文里是否包含某个关键词。用户把数据加密后上传，之后想搜某个词，就发一个“陷门”（trapdoor），服务器拿着这个陷门去匹配密文，返回匹配的结果。整个过程数据始终是密的。

你想想看，如果只是简单地把每个单词用 AES 加密，那同一个单词每次加密结果都不同，服务器根本无法比对。所以 SSE 必须引入 确定性加密 或 伪随机函数（PRF），让相同关键词生成相同的密文标识。

SSE 的两种基本模型

我从工程角度把 SSE 模型分成两类：

• 非自适应模型 (Non-Adaptive) —— 搜索模式固定，一次生成所有陷门；安全性分析相对简单，但实用性差。
• 自适应模型 (Adaptive) —— 用户可以基于之前的搜索结果继续搜索；现实中几乎都用这种。

之前那个医疗项目，我们一开始选了非自适应方案，结果业务方要求“搜完 A 再搜 B”，没法处理。后来全盘重写成了自适应版本，才搞定。

标准 SSE 方案流程

拿经典的 Curtmola-Garay-Kamara-Ostrovsky 方案（CGK） 来说，它分三个阶段：

1. Setup（初始化）：用户生成密钥 K，对文档集合构建索引并加密，将（密文 + 索引）上传。
2. （陷门生成）：用户想搜关键词 w，用 PRF 计算陷门 t = F(K, w)，发给服务器。
3. Search（搜索执行）：服务器用陷门在密文索引中查找，返回匹配的文档 ID 或密文。

SSE 的安全性定义

安全性是这门课的重头戏。SSE 的安全性通常用 IND-CKA（选择关键词攻击下的不可区分性） 来刻画。我翻译成人话：

• 服务器除了知道“某次搜索命中了哪些密文”之外，无法获取其他信息。
• 理想情况下，服务器看到的就是一堆随机字符串。

但是，现实中有个“泄漏函数”你逃不掉。比如搜索模式（相同陷门对应相同关键词）、访问模式（哪些文档被命中）。我自己做过一个实验：如果只泄漏搜索模式，攻击者依然可以通过频率分析恢复出大部分关键词。所以安全性不是的，要看你泄漏多少。

你开发 SSE 系统时，一定要先问客户：“你们能接受泄露哪些信息？” 不同业务场景，容忍度天差地别。

经典 SSE 方案对比

我整理了几个常见方案的关键差异：

我个人建议：如果数据不常变，直接上 CGK 的静态方案；如果需要频繁增删改，就考虑 DSSE 或基于 j-parties 的思路。

核心流程图：SSE 全生命周期

下面这张图概括了 SSE 从初始化到搜索执行的完整流程。我把它画成逻辑流程图，方便你对照理解：

工程实现中的关键细节

SSE 听起来理论完整，但落地时我踩过几个坑：

另外，生产环境下的 SSE 一定要考虑 搜索可验证性。有一次我排查 bug 发现服务器偷懒只返回了部分结果，但客户端完全不知道。后来加了 认证数据结构（如 Merkle 树），才保证搜索结果的完整性。

SSE 的适用场景

• 云存储搜索：用户把自己的加密照片/文档上传，后期按关键词检索。Dropbox 的某些安全扩展就用类似思路。
• 医疗数据共享：医院加密病历后放云端，医生经过授权才能搜索特定病症。
• 日志审计：企业把加密日志上传给外部审计平台，审计方只能在给定陷门下搜索特定 IP 或事件。

我个人的经验是：如果数据量在百万级以下，静态 SSE（如 CGK）完全可以胜任；动态 SSE 虽然支持更新，但性能开销大，要谨慎评估。

最后说一句

SSE 不是万能的。它保护了 数据机密性，但 搜索模式 和 访问模式 的泄露在某些强监管场景下可能引发合规风险。比如 GDPR 要求“无法推断出任何用户行为信息”，这时 SSE 就不够了，得配合 不透明随机访问机（ORAM） 或 差分隐私。不过那是后话，先把 SSE 这个基础打牢，后面的课程才更好理解。