📚 课程目录第4章可搜索加密概述

4. 对称可搜索加密（SSE）核心概念与归纳

聊到可搜索加密，大家最先接触的肯定是对称可搜索加密。说白了，就是给你一箩筐加密后的数据，你还想在里面找关键词。不能解密，又要搜——SSE 干的就是这活儿。

我最早接触 SSE 是在做审计日志巡检项目的时候。当时面对海量加密日志，老板问「能不能按用户 ID 查一下上周的异常记录？」我一愣，心想：全解密再搜？那加密意义何在……后来才发现，SSE 就是为这种场景设计的。

4.1 什么是 SSE？

SSE 的全称是 Symmetric Searchable Encryption。它允许数据拥有者将数据加密后外包给服务器，同时保留关键词搜索能力。服务器拿到你的搜索指令（陷门）后，能在不解密的情况下找到匹配的密文记录。

跟传统搜索比，差别很明显：

对比项	全量解密搜索	SSE 搜索
安全性	解密后数据暴露	始终加密，服务器看不到明文
效率	O(n) 解密 + O(n) 扫描	O(1) ~ O(log n) 查找索引
适用场景	本地自用	云 / 受控第三方审计

我的习惯：在实际项目选型时，先问自己「服务器是否完全不可信？」如果是，SSE 是不二之选；如果只是部分可信，可以考虑效率更高的变体。

4.2 SSE 的工作流程

来看一个典型的 SSE 流程，我把它拆成几步：

建立索引：数据拥有者从文档中提取关键词，构建倒排索引（每个关键词对应一组文档 ID）。
加密索引：用对称密钥加密索引结构。常见做法是用伪随机函数（PRF）对关键词做映射，再用对称加密加密文档 ID 列表。
加密文档：用 AES 等对称算法加密文档本身。
外包：把加密后的索引和加密文档一起交给服务器。
查询：用户要搜索某关键词时，用密钥和关键词生成陷门（trapdoor），发给服务器。
搜索：服务器拿陷门去查加密索引，定位到匹配的密文位置。
返回：服务器把对应的加密文档返回给用户，用户本地解密。

嗯，这里要注意：陷门生成只能用对称密钥，不能泄露关键词本身。我曾经在早期版本里直接用关键词的哈希当作陷门，结果被安全审查打回——哈希太容易被彩虹表反向。后来改用 Keyed PRF 才过关。

下面这段伪代码展示了核心逻辑：

// 关键词加密索引构建（简化版）
for each keyword w in document d:
  // 用 PRF 生成 w 的标识符
  tag = PRF(key, w)
  // 用对称加密加密文档 ID 列表
  enc_ids = AEAD(key, ids(w))
  // 存储到索引
  index[tag] = enc_ids

// 搜索陷门生成
trapdoor = PRF(key, query_word)

// 服务器搜索
enc_ids = index[trapdoor]  // 若存在，则返回

  关键点：整个搜索过程服务器只接触到加密后的标识符和密文，无法推断任何明文信息，除非它攻破 PRF 或对称加密。

4.3 SSE 的安全模型

做 SSE 你不能只问「安全不安全」，要问「泄露了什么」。因为任何 SSE 方案都会泄露一些侧面信息，比如：搜索模式（同一个陷门出现多次说明搜了同一个词）、访问模式（哪些文档被命中）。

举两个常见模型：

非自适应安全：攻击者选定查询后一次性执行，无法根据之前结果调整后续查询。历史上早期的 SSE 方案多属此类。
自适应安全：攻击者可以按顺序查询，每次查询都能观察搜索结果，再决定下一步。更贴近现实，但设计也更复杂。

安全模型	泄露范围	典型方案	实际选型经验
非自适应	仅泄露搜索模式	SWP (2000)	适合静态数据集，如历史日志归档
自适应	泄露搜索模式 + 访问模式	Curtmola et al. (2006)	适合动态审计，日志持续写入的场景

我曾经踩过的坑：在审计日志巡检项目初期，我采用了非自适应方案，认为日志只查一次就够了。结果业务方要求能反复按同一关键词追踪异常用户——搜索模式立刻暴露，第三方服务商能看到查询频率曲线，差点造成信息泄露。后来重构时果断换成了自适应安全方案。

4.4 主流 SSE 方案对比

SSE 发展了二十多年，方案很多。我挑几个有代表性的说说：

SWP 方案（Song, Wagner, Perrig 2000）：开山之作。每个单词加密后嵌在文档里，搜索时逐个试探。优点是简单，缺点是搜索时间与文档长度成正比。
Curtmola 方案（2006）：引入倒排索引 + 伪随机函数，查询时间降到常数级。这是现代 SSE 的基石。我现在大多数项目都用它的变体。
Cash 等人方案（2013）：带动态更新，支持添加/删除文档，适合日志系统。
Bost 方案（2016）：利用字典树结构，查询更快，但内存开销大。

下面是快速对比表格：

方案	提出年份	搜索复杂度	支持动态	典型泄露
SWP	2000	O(length of document)	否	文档内单词位置
Curtmola	2006	O(1) → O(#matches)	否	搜索模式 + 访问模式
Cash et al.	2013	O(1) → O(#matches)	是（更新）	同 Curtmola + 更新模式
Bost	2016	O(log n)	是	查询模式

我建议：如果你做的是面向静态归档的审计日志巡检，Curtmola 方案足够用；如果要实时写入新日志（比如 SIEM 系统），必须选支持动态更新的方案，可以看看 Cash 或 Bost 的变体。

4.5 SSE 在审计日志场景中的实践要点

把 SSE 接入审计日志流程，有几点你需要留神：

索引粒度：审计日志通常是按时间、操作、用户等字段搜索。我习惯把关键词建在「事件类型」和「用户ID」上，日期字段用范围查询配合 SSE 扩展（比如字段级加密）。
泄露控制：日志巡检的查询模式很容易被统计（比如每天查同一个关键词多少次）。如果对手能观察查询频率，就可能推断业务模式。可以考虑引入陷门混淆，比如用假查询稀释真实查询——虽然增加开销，但值得。
性能取舍：SSE 的搜索速度远快于全量解密，但建立索引和加密文档需要额外计算。我建议在日志入库时异步建立加密索引，不要等查询时才处理。
密钥管理：对称密钥必须安全分发。审计系统多为多个审计员共用数据，你可以考虑用 KMS 或密钥派生树（每次查询衍生出临时陷门密钥）。

警告：千万别自己手写 SSE 核心实现。我在一个原型项目里尝试自己造轮子，结果因为伪随机函数选择不当（用了弱 MD5），导致陷门可以被碰撞攻击。老老实实使用经过密码学审计的库，比如 libsodium 或 OpenSSL 的对称加密 + HMAC 组合。