2. 安全查询的威胁模型与安全目标
在密文索引与安全查询工程中，讨论“安全性”之前必须先回答三个问题：谁在攻击、攻击者能看到什么、我们希望保护到什么程度。这三者分别对应敌手能力、泄露函数与安全目标。若跳过威胁模型直接谈加密方案，往往会出现“算法本身安全，但部署后被流量分析击穿”的错位。本节围绕这三个问题展开，并给出前向安全与后向安全的精确定义。
一、敌手能力：从被动观察到主动注入
敌手能力刻画攻击者能执行哪些操作、能获取哪些信道。工程上通常按能力递增分为若干档，方案设计必须明确“防到哪一档”。
- 被动敌手（Passive / Honest-but-Curious）：只监听网络与存储，不篡改、不注入。典型如云存储服务商读取密文索引与查询令牌。
- 主动敌手（Active）：可注入伪造查询、重放旧令牌、篡改索引条目，甚至删除或回滚数据。回滚攻击是后向安全要重点应对的场景。
- 自适应敌手（Adaptive）：查询令牌的构造可依赖此前观察到的所有泄露，而非预先固定查询集合。自适应模型更贴近真实攻击，也更难证明。
- 快照敌手（Snapshot）：在某一时刻获取数据库与索引的完整快照，之后结合后续查询令牌推断历史内容。前向安全正是针对此类敌手。
需要强调：敌手能力不是越强越好，而是要与部署环境匹配。若服务端完全可信，则无需前向安全；若服务端可能被入侵并留存快照，则前向安全是硬性要求。
二、泄露函数：把“不可避免的泄露”显式化
可搜索加密无法做到零泄露，因为查询本身会暴露访问模式。泄露函数（Leakage Function）把方案在理想执行中必然暴露的信息形式化为若干分量，常见包括：
- 搜索模式（Search Pattern）：哪些查询检索了同一个关键词，即查询间的等价关系。
- 访问模式（Access Pattern）：每次查询命中的文档标识集合。
- 结果规模（Result Size）：命中数量，常与访问模式合并考虑。
- 更新模式（Update Pattern）：插入、删除操作的时间与数量分布。
- 体积泄露（Volume）：密文长度、令牌长度等可测量量。
泄露函数是安全证明的“合同”：方案承诺除 L 之外不泄露任何信息。工程评估时应把 L 与真实业务敏感度对照——例如访问模式泄露在关键词基数极低时可能直接暴露查询内容。
三、前向安全与后向安全：定义与区别
前向安全（Forward Privacy）与后向安全（Backward Privacy）刻画的是更新操作与历史查询之间的隔离关系，二者方向相反，必须分别定义。
前向安全定义：对于任意在时间 t 执行的更新操作，敌手即使掌握了 t 之前所有查询令牌与泄露信息，也无法判断该更新是否与某个历史关键词相关。换言之，新更新不会泄露其与旧查询的关联。典型实现是让每次更新的索引位置由独立随机数派生，使旧令牌无法定位新条目。
后向安全定义：对于已删除或已更新的条目，敌手即使掌握该条目对应的历史查询令牌，也无法从后续查询结果中获知其内容或存在性。后向安全通常分为若干强度等级：
- Type-I：删除后，历史令牌无法再检索到该条目。
- Type-II：删除后，历史令牌无法检索到该条目，且新令牌也不暴露该条目曾被删除。
- Type-III：进一步要求删除操作本身不泄露被删条目的关键词信息。
方向约定：前向安全保护“未来更新不被过去令牌推断”，后向安全保护“过去条目不被历史令牌追溯”。二者共同构成动态可搜索加密的核心安全目标。
四、工程落地：如何把定义转化为可检查的约束
定义只有落到实现细节才有意义。以下给出一个可参考的检查清单，用于评估一个动态可搜索加密方案是否满足本节所述安全目标。
| 检查项 | 对应定义 | 判断依据 |
|---|---|---|
| 更新令牌是否含独立随机数 | 前向安全 | 旧查询令牌无法定位新条目位置 |
| 删除是否真正移除可检索性 | 后向安全 Type-I | 历史令牌检索结果为空 |
| 删除是否隐藏“曾存在” | 后向安全 Type-II | 新令牌不暴露删除痕迹 |
| 删除是否隐藏关键词 | 后向安全 Type-III | 删除操作不泄露被删关键词 |
| 泄露函数是否显式声明 | 泄露函数 L | 安全证明中给出 L 的完整分量 |
| 敌手是否自适应 | 敌手能力 | 证明覆盖查询依赖历史的场景 |
以一个教学示例说明：假设关键词 w 在 t₁ 被查询，t₂ 插入文档 d，t₃ 删除 d，t₄ 再次查询 w。若方案满足前向安全，则 t₂ 的更新令牌与 t₁ 的查询令牌无关联，敌手无法从 t₁ 推断 d 与 w 的关系；若满足后向安全 Type-II，则 t₄ 的查询结果中 d 不出现，且敌手无法从 t₄ 令牌判断 d 曾被删除。这两个性质分别由不同的密码学机制保障，不能互相替代。