第三章 可搜索加密概念：安全模型、索引与陷门
可搜索加密，说白了就是「既能加密，又能搜」。不用把数据全解密出来，直接在密文上查关键字。听起来很酷对吧？我早年做第一个密文检索项目时，老觉得这是黑魔法。后来一步步拆开看，发现核心就三个东西：安全模型定规矩，索引搭架子，陷门当钥匙。
3.1 安全模型——你防的是谁？
先聊安全模型。不同场景，对手的能耐不一样，咱们的设计也得不一样。我个人习惯把安全模型分成三个等级：
| 模型等级 | 对手能力 | 典型场景 |
|---|---|---|
| 已知密文模型（CKA1） | 只能看到密文，不能发起查询 | 静态数据归档 |
| 已知明文攻击（CKA2） | 能看到密文，还能知道部分明文-密文对 | 半可信云存储 |
| 自适应选择关键字攻击（IND-CKA2） | 能逐步根据之前查询结果调整攻击策略 | 动态数据库、高安全要求场景 |
核心原则：安全模型必须与业务威胁对齐。别过度设计，也别偷工减料。
我记得刚入行时，总想一步到位用IND-CKA2。后来发现很多内部系统，攻击者连数据库都接触不到，CKA1就够用了。过度设计只会让性能崩掉。
我的小建议：先问自己三个问题——数据在哪？谁可能碰它？他能做哪些操作？答案决定了你选哪种模型。
3.2 索引——给密文搭个架子
没有索引，每次查询都得扫描整个密文库。想象一下，你要在1000本书里找一句台词，不翻目录，一本一本翻——累不累？
索引就是一种「预先计算好的查找结构」。在可搜索加密里，索引通常包含两部分：
- 关键字列表：每个文档有哪些关键字，提前提取好
- 安全索引结构：用加密算法把关键字映射成密文位置，服务器看不懂关键字本身，但能比对
我参与过一个日志检索项目，日志量每天上亿条。索引如果设计不好，查询延迟直接飙到秒级。后来我们用了倒排索引加布隆过滤器的组合，才压到几十毫秒。
3.3 陷门——你手里那把钥匙
陷门就是「搜索令牌」。用户发起查询时，不是把关键字明文发出去，而是用密钥生成一个陷门。服务器拿着陷门去对比索引，匹配就返回对应文档。
陷门有两个关键特性：
- 确定性：同一个关键字生成的陷门必须相同，否则无法匹配
- 不可逆：从陷门恢复关键字在计算上不可行
注意：确定性也带来了侧信道风险——相同关键字被多次查询，攻击者可以统计其频率。我曾经遇到一个金融项目，对方要求加「关键字隐私保护」，最后我们给每个陷门加了个计数随机化，才堵上这个洞。
3.4 流程串联：一次完整查询
把三个概念串起来看：
用户端：
1. 提取文档关键字集合
2. 用密钥构建安全索引（密文索引）
3. 加密原始文档（密文数据）
4. 上传索引+密文到服务器
查询时：
1. 用户输入关键字
2. 用相同密钥生成陷门
3. 发送陷门到服务器
服务器端：
1. 接收陷门
2. 在索引中匹配（陷门与索引条目比对）
3. 返回匹配的密文文档标识
4. 用户下载后解密嗯，这里要注意：服务器全程不知道关键字是什么，只知道「这个陷门和索引里某个条目对上了」。
3.5 安全模型与索引、陷门的关系
不同安全模型下，索引和陷门的实现细节会变。比如：
| 模型 | 索引特点 | 陷门特点 |
|---|---|---|
| CKA1 | 静态索引，构建后不更新 | 陷门固定，可缓存 |
| CKA2 | 索引可包含随机化元素 | 陷门依赖密钥，防伪造 |
| IND-CKA2 | 索引带随机扰动，防频率分析 | 每次查询陷门可变，但仍能匹配 |
一句话总结：安全模型越高，索引和陷门的设计就越「花哨」，但性能代价也越大。
3.6 一张图看懂全貌
下面这个图帮你理清三个概念的关系和流程：
3.7 避坑指南——我踩过的几个坑
- 索引不加密直接存：千万别！我就见过一个组把关键字哈希后当索引，以为安全了，结果被人建彩虹表全猜出来。一定要用密钥参与的伪随机函数。
- 陷门与密钥绑定不足：如果陷门脱离了密钥绑定，任何人都可以生成任意关键字的陷门。记得做到「密钥不知道，陷门出不来」。
- 忽略统计安全：IND-CKA2模型要求索引带随机化，但很多人图省事用了确定性方案。我曾经在一个医疗数据项目里被迫重构，就是因为攻击者通过查询频率推测出了疾病分布。
一个小经验：刚上手时先用CKA1跑通全流程，再根据威胁分析逐步升级安全等级。一上来就搞IND-CKA2，调试复杂度会让你崩溃。
好了，这一章把三个概念拆开讲了。安全模型是你的安全承诺，索引是你的数据结构，陷门是你的搜索钥匙。三者配合好了，可搜索加密才真正可用。