4. 倒排索引与正向索引的密文化改造

在明文检索系统中，正向索引与倒排索引承担着互补的角色：正向索引以文档标识符（DocID）为主键，记录该文档包含哪些关键词；倒排索引以关键词为主键，记录该关键词出现在哪些文档中。一旦把数据托管到不可信服务器，这两类索引都会直接泄露文档内容、主题分布和访问模式。密文索引改造的目标，是在保留“按关键词找文档”这一核心能力的同时，让服务器无法从索引本身推断出关键词、文档标识符以及它们之间的对应关系。

一、两类索引的密文化改造思路

正向索引的密文化相对直接：把每个文档的关键词集合整体加密，形成一条“加密文档记录”，服务器只保存 DocID → Enc(关键词集合) 的映射。查询时客户端先取回目标文档的加密记录，在本地解密后再做匹配。这种方式实现简单，但每次查询都要拉取整条记录，通信开销随文档关键词数量线性增长，适合文档数量少、关键词集合小的场景。

倒排索引的密文化更复杂，因为它必须支持“给定关键词，直接定位文档集合”。常见做法是引入关键词令牌（Token）：客户端用密钥对关键词做确定性加密或 HMAC，得到固定长度的检索令牌，服务器以令牌为键存储文档标识符列表。这样服务器看到的是 Token(kw) → [Enc(DocID₁), Enc(DocID₂), …]，既不知道关键词原文，也不知道文档的真实标识。

二、关键词映射与文档标识符加密

关键词映射的关键在于“确定性”与“不可区分性”的平衡。若对关键词直接做 AES-CBC 等随机化加密，同一关键词每次加密结果不同，服务器无法把它们归并到同一个倒排桶里，倒排索引就失效了。因此关键词令牌通常采用 HMAC-SHA256 或确定性加密（如 AES-SIV）：

Token(kw) = HMAC-SHA256(K_token, normalize(kw))
// normalize: 转小写、去停用词、词干化，保证语义相同的关键词归一

文档标识符则相反，必须使用随机化加密，例如 AES-GCM，并携带随机 IV。这样同一个 DocID 在不同倒排桶中密文不同，服务器无法通过密文比对判断“这两个关键词出现在同一文档”。文档标识符加密后通常还会附加一个盲化索引或伪随机 DocID，用于后续取回文档密文时定位存储位置。

下面这张图展示了从明文文档到密文倒排索引的完整映射关系，以及查询时令牌如何驱动检索：

三、查询流程与访问模式保护

一次完整的密文查询流程如下：用户输入关键词后，客户端先做归一化，再用 K_token 计算令牌并发送给服务器；服务器以令牌为键查找倒排桶，返回该桶内的加密 DocID 列表；客户端解密 DocID，再按伪随机存储位置取回文档密文，本地解密后排序展示。整个过程中，服务器只看到令牌和密文，无法还原关键词或文档内容。

但仅做到“内容加密”还不够。服务器仍然能观察到访问模式：哪些令牌被频繁查询、哪些桶经常被一起访问、查询返回了多少条结果。攻击者可以结合辅助信息（如已知某些文档的主题）做统计推断。因此工程上通常叠加以下保护手段：

• 桶填充：把每个倒排桶填充到固定长度，隐藏真实文档数量。
• 查询混淆：每次查询附带若干随机假令牌，服务器无法区分真实查询与噪声。
• 令牌轮换：定期更换 K_token 并重建索引，切断长期访问模式积累。
• 前向安全：新增文档时使用新密钥派生令牌，使旧令牌无法解密新桶，防止历史查询推断新内容。

四、正向索引与倒排索引的协同

在实际系统中，两类索引往往同时存在。倒排索引负责“关键词 → 文档”的快速定位，正向索引负责“文档 → 关键词集合”的更新与校验。密文化后，正向索引的加密记录可以作为倒排索引的补充：当需要删除某文档时，客户端先解密该文档的正向记录，得到其关键词集合，再逐个计算令牌并更新对应倒排桶。这样既避免了服务器直接操作明文关键词，也保证了索引一致性。

需要特别注意的是，关键词映射的归一化规则必须在客户端统一执行，且规则本身不应泄露给服务器。如果服务器能观察到“两个不同令牌总是同时出现”，仍可能推断出关键词之间的语义关联。因此，令牌生成应绑定文档或时间维度，必要时引入盲签名或可搜索加密方案，让服务器在完全不知道关键词的前提下完成匹配。

总结来看，倒排索引与正向索引的密文化改造，本质是把“索引结构”拆成客户端可信域和服务器不可信域两部分：客户端掌握密钥、归一化规则和令牌生成逻辑，服务器只存储令牌到密文 DocID 的映射以及密文文档块。查询流程围绕令牌展开，访问模式则通过填充、混淆和密钥轮换加以保护。理解这一分工，是后续实现可搜索加密和安全查询协议的基础。