18、数据隐私保护：碎片化与加密的结合应用

数据隐私保护：碎片化与加密的结合应用

在当今数字化时代，数据隐私保护至关重要。为了高效地执行数据集合上的隐私约束，同时兼顾查询执行效率，我们可以采用一种将数据碎片化和加密相结合的方法。下面将详细介绍这种方法的相关内容。

1. 查询映射与执行

在处理查询时，查询映射组件会将查询进行转换。例如，对于查询Q，会转换为服务器在片段上执行的查询Qs.3（符号Qs.x表示服务器在片段x上执行的查询）以及应用程序执行的查询Qu。服务器执行的查询Qs.3仅将属于最终结果的元组返回给应用程序，应用程序只需对这些元组进行解密，以投影出所需的属性，如SSN和Name。

考虑一个查询Q′，它用于检索患有乳胶过敏（Latex al.）、邮政编码为94140且职业为护士的患者的社会安全号码（SSN）和姓名。假设片段ˆF3包含疾病（Sickness）和邮政编码（ZIP）信息，且S(Q′,F3)=1/6；片段F2仅包含职业（Occupation）信息，且S(Q′,F3)=1/3。查询映射组件会将查询Q′转换为服务器在片段上执行的查询Q′s.3和应用程序执行的查询Q′u。由于邮政编码在片段ˆF3中并非以明文形式出现，因此该条件需要由应用程序进行评估，并且应用程序在解密Qs.3计算的结果后，还需执行对SSN和Name属性的投影操作。

对于WHERE子句中包含否定条件的查询，查询映射组件可以轻松处理。因为只要基本条件c可以在物理片段上进行评估，其否定条件（即NOT(c)）也可以在同一片段上进行评估。然而，对于WHERE子句中包含析取条件的查询，则需要特殊考虑。根据OR运算符的语义，某些无法在片段上评估但与其他可在片段上评估的条件进行析取的条件，不能像处理合取条件那样简单地在服务器返回的结果上进行评估。此时可能出现以下三种情况：
- 情况一 ：查询的条件部分可以简化为合取范式，那么查询映射和评估可以按照上述合取情况进行。
- 情况二 ：查询的条件部分可以简化为析取范式，且所有组件都可以在不同的片段上进行评估。在这种情况下，查询映射组件会要求服务器执行与析取组件数量相同的查询，并将它们的结果进行合并（并集操作）。
- 情况三 ：查询的条件部分包含一个基本条件（需与其他条件进行析取评估），该条件无法在任何片段上进行评估（例如涉及敏感属性或出现在两个不同片段中的属性）。在这种情况下，查询映射组件需要检索整个片段（任何片段均可），并在其位置评估查询条件。

2. 索引类型及其特点

在加密数据库中，对加密数据的查询通常通过在加密属性上构建的索引来评估。每个明文查询会被转换为对索引的查询，然后由可信客户端对结果（可能包含虚假元组）进行解密和过滤。主要有以下三种类型的索引：
|索引类型|获取方式|特点|
| ---- | ---- | ---- |
|直接索引|对属性的明文值应用无盐加密函数得到|在加密数据库场景中最有效，明文值条件与索引值条件存在一一对应关系，但存在重大漏洞，仅适用于受限情况|
|哈希索引|对明文值应用带密钥的哈希函数，并限制结果以产生冲突得到|仅在存在异常值或在同一表中使用多个索引时可能产生暴露问题，否则可保证机密性|
|扁平化哈希索引|与哈希索引类似，应用带密钥的哈希函数产生冲突，同时进行后处理以扁平化索引值的分布|提供更好的保护，可避免异常值的暴露|

3. 索引在碎片化数据中的应用及风险

虽然上述索引在加密数据库中有各自的特点，但将索引应用于碎片化数据（与加密数据库不同，碎片化数据会报告一些明文值）时会引入新的漏洞。为了识别索引的安全使用方式，我们需要考虑对手可能拥有的知识，主要包括垂直知识和水平知识：
- 垂直知识 ：由于保密约束，一个片段中未以明文形式出现的值可能在其他片段中以明文形式出现。对手无需额外的外部信息，除了属性出现在单例约束中的情况，他们可以从其他可访问的片段中获取这些信息。例如，通过观察片段，对手可以完全了解索引属性的分布（明文值及其出现次数）。
- 水平知识 ：对手可能拥有关于表中特定元组（对应敏感关联）存在的外部知识。最简单的形式是对手知道单个元组（v1, v2）。例如，对手可能知道A. Smith患有乳胶过敏，即（A. Smith, latex al.）属于原始表R。

在垂直和水平知识的假设下，不同类型的索引在碎片化数据中存在不同的暴露风险：
|索引类型|知识类型|暴露风险情况|
| ---- | ---- | ---- |
|直接索引|垂直知识（di - vk）|敏感关联的暴露取决于索引值出现次数的可区分性。例如，对应乳胶过敏的索引由于是唯一出现三次的索引，对手可以推断出A. Smith、B. Jones和C. Taylor患有乳胶过敏，而对于其他三名患者，对手可以估计他们患有其他三种疾病的概率相等|
|直接索引|水平知识（di - hk）|对手通过结合在索引片段中以明文形式出现的属性（如Name）的知识，可以检索到与索引属性（如Sickness）的特定明文值对应的索引值λ，从而暴露具有相同索引值的关联|
|哈希索引|垂直知识（hi - vk）|哈希索引减少了关联的暴露，因为不同的明文值可能由相同的索引值表示。但出现次数较多的值（异常值）通常仍可识别。例如，对手可以推断出索引σ对应乳胶过敏，因为它是唯一至少出现3次的索引，进而推断出4名患者中有3名患有乳胶过敏（即每人患有乳胶过敏的概率为0.75）|
|哈希索引|水平知识（hi - hk）|对手可以识别代表已知明文值的索引值，且该索引值可能对应其他明文值。对手可以推断出某些关联不在数据库中，并结合垂直知识，推断出某些敏感关联属于数据库的概率|
|扁平化哈希索引|垂直知识（fhi - vk）|由于扁平化了索引值的出现次数，无法根据出现次数建立明文值和索引值之间的对应关系，因此对垂直知识不敏感|
|扁平化哈希索引|水平知识（fhi - hk）|对手可以识别代表已知明文值的索引值，并结合垂直知识，识别可能与已知索引的明文值相关联的元组子集，并估计它们关联的概率|

综上所述，垂直和水平知识会基于明文（及相应索引）值的出现次数产生推理风险。即使值均匀分布，所有上述索引仍易受水平知识的影响，对手可以推断出与已知明文值的关联。当值均匀分布且水平知识涉及仅出现一次的索引值的关联时，这些漏洞可以被阻止。当索引指向候选键属性时，这两个条件肯定会得到满足。因此，在不损害片段机密性的情况下，我们可以在对应原始关系候选键的属性上应用索引。

索引可以轻松集成到成本模型中，只需细化Cost(Q,F)函数。具体操作是考虑索引对索引值条件的选择性。索引不会影响成本函数在片段上的单调性，因此不会影响解决方案的适用性。例如，对于SSN和Name（假设Name是候选键），可以在它们以加密形式出现的任何片段中考虑使用直接索引（对于SSN，所有片段都适用；对于Name，图4.2(b)和图4.2(c)中的片段适用）。

下面是一个简单的mermaid流程图，展示了查询执行和索引评估的大致流程：

graph LR
    A[查询Q] --> B[查询映射组件]
    B --> C[服务器执行查询Qs.3]
    C --> D[返回结果给应用程序]
    D --> E[应用程序执行查询Qu并解密投影]
    F[加密数据库查询] --> G[转换为索引查询]
    G --> H[可信客户端解密过滤]

通过以上对查询映射、索引类型以及索引在碎片化数据中的应用和风险的介绍，我们可以更好地理解如何结合碎片化和加密来保护数据隐私，并在实际应用中做出更合理的决策。

数据隐私保护：碎片化与加密的结合应用

4. 实验结果分析

为了评估相关算法的性能，我们对启发式算法进行了实验，并与完整搜索算法的结果进行了比较。实验中考虑的关系模式由19个属性组成，灵感来源于医疗信息数据库，同时设置了多达18个保密约束，这些约束由2到4个属性组成。我们还使用伪随机生成函数生成了亲和矩阵的内容，并考虑了14个具有不同频率值的查询。实验考虑了属性数量从3到19的不同配置，每个配置仅考虑完全适合所选属性的约束。

4.1 执行时间比较

图4.20比较了完整搜索算法和启发式算法的执行时间。由于最小化片段数量、最大化亲和性和最小化成本同时满足保密约束的问题是NP难问题，三种完整搜索策略所需的时间随着属性数量的增加呈指数增长。即使有大量的计算资源，对于较大的配置，完整搜索也变得不可行（在实验中，我们只能对属性少于15的模式运行完整搜索）。相比之下，启发式分析所需的时间始终较低。计算向量最小碎片化和最大化亲和性的向量最小碎片化的启发式函数的计算时间接近0。而最小成本碎片化问题的启发式算法所需的时间随着前瞻深度的增加呈指数增长，随着并行步骤数量的增加呈线性增长，但对于最简单的搜索（d = 1, ps = 1），时间仍然有限。因此，拥有一系列启发式算法非常重要，这样在实际系统中可以采用动态方法，最初使用最有效的启发式算法进行搜索，根据可用资源增加深度。并行步骤数量对于在多核架构上实现启发式算法尤为重要，每个核心可以管理一个替代方案的探索。

以下是执行时间比较的大致情况列表：
- 完整搜索算法：
- 执行时间随属性数量增加呈指数增长。
- 对于属性少于15的模式才可行。
- 启发式算法：
- 计算向量最小碎片化和最大化亲和性的启发式函数计算时间接近0。
- 最小成本碎片化问题的启发式算法：
- 时间随前瞻深度增加呈指数增长。
- 时间随并行步骤数量增加呈线性增长。
- 最简单搜索（d = 1, ps = 1）时间有限。

4.2 解决方案质量比较

• 片段数量 ：图4.21比较了启发式算法计算的向量最小碎片化的片段数量与完整搜索函数计算的结果。在所有可比较的情况下，启发式算法始终能识别出最优解决方案。
• 亲和性 ：图4.22比较了启发式算法计算的碎片化的亲和性与完整搜索策略产生的最优亲和性。在所有可比较的情况下，启发式算法计算的解决方案的亲和性接近最优值，平均差异为4.2%，最大百分比差异约为14.1%。
• 成本 ：
  • 图4.23(a)比较了启发式算法在两种配置（d = 1, ps = 1和d = 3, ps = 1）下获得的解决方案的成本与完整搜索策略产生的最优成本。即使是最简单的配置（d = 1, ps = 1）也能保证高质量的碎片化。
  • 图4.23(b)显示了启发式算法在参数ps取不同值（1、3和5）且d = 1固定时产生的解决方案的成本。使用ps = 5即可获得接近最优的碎片化。

以下是一个表格总结解决方案质量比较：
|比较指标|启发式算法表现|
| ---- | ---- |
|片段数量|在可比较情况下，始终识别出最优解|
|亲和性|接近最优值，平均差异4.2%，最大差异约14.1%|
|成本|简单配置（d = 1, ps = 1）保证高质量碎片化，ps = 5可获接近最优碎片化|

4.3 索引的效益评估

实验还评估了索引的效益，结果表明（见图4.24），在加密属性上使用索引可以产生显著的效益。效益的大小高度依赖于关系模式和查询配置的特定特征。

5. 总结与展望

通过将碎片化和加密相结合的方法，我们可以有效地实施数据集合上的隐私约束，同时提高查询执行效率。所提出的碎片化算法考虑了系统的可用信息，以高效地执行碎片化数据上的查询。

这种方法不仅具有技术贡献，还可以为隐私法规的有效实施和建立迈出重要一步。技术限制被认为是无法实现隐私以及无法实施法规的主要原因之一，沿着本文思路的研究可以为更精确地指定隐私需求和法规提供基础，同时将隐私要求更清晰、直接地集成到现有的信息通信技术基础设施中。

在实际应用中，我们可以根据具体的需求和场景，选择合适的索引类型，并结合启发式算法进行数据处理，以在保护数据隐私的同时，实现高效的查询执行。以下是一个总结性的mermaid流程图，展示了整个数据隐私保护方案的主要流程：

graph LR
    A[数据集合] --> B[碎片化与加密处理]
    B --> C[应用索引]
    C --> D[执行查询]
    D --> E[评估结果]
    E --> F[根据结果调整策略]
    F --> B

总之，通过合理运用碎片化、加密和索引技术，并结合有效的算法和策略，我们可以更好地保护数据隐私，满足各种应用场景的需求。