全密态数据库学习

weixin_38700215

于 2025-04-03 13:26:50 发布

阅读量668

点赞数 12

文章标签：安全数据库密码学 postgresql 同态加密

本文链接：https://blog.csdn.net/weixin_38700215/article/details/146978786

版权

概念

“全密态数据库”指的是一种在整个数据生命周期内都保持加密状态的数据库系统，也就是说数据在存储、传输和计算过程中始终是加密的。这种设计理念可以大大降低数据泄露的风险，即使在进行数据运算时，也不需要将数据解密，从而极大地提高安全性。简单的说就是数据在客户端就加密，发送到服务端存储，数据加减乘除、创建索引、排序、比较等操作全部在服务端以密文为基础进行处理，仅仅将密文形式的查询结果返回到客户端，客户端再将结果解密为明文。

全密态数据库利用诸如全同态加密（FHE）、安全多方计算（SMC）等先进的加密技术实现对数据的全周期保护。其主要特点包括：

全程加密：数据在处于静态（at rest）、传输中（in transit）以及被处理或运算（in use）时都是加密状态。
隐私保护计算：允许在不解密数据的前提下直接对加密数据进行计算（如加法、乘法等运算），这通常依赖于全同态加密。
风险控制：即使数据库管理员或云服务提供商也无法直接获取数据的明文，降低内部和外部的安全威胁。

当前全密态数据库及相关技术产品

目前，真正实现全密态操作的数据库系统还处于研发和原型阶段，且商业化产品较少。下面是一些与全密态数据库或相关加密计算技术密切相关的项目和产品：

全同态加密库（作为构建全密态数据库的基础组件）：
- Microsoft SEAL：微软推出的全同态加密库，虽然不是一个完整的数据库系统，但为数据加密计算提供了基本支持。
- IBM HELib：IBM支持的开源全同态加密实现，也是研究和实验项目中常用的工具。
实验性和概念性系统：
- CryptDB：一个学术项目，其设计探索了如何在数据库中对加密数据进行查询和计算，尽管其实现上不能做到完全加密运算，但为全密态数据库提供了重要的思路。
- MonomiDB：一些研究团队基于学术实验开发了此类系统，以验证在数据库中实现全密态计算的可行性。
商业隐私保护解决方案：
- Enveil ZeroReveal：这是一种数据隐私平台，提供对敏感数据的加密计算功能，其技术路线与全密态数据库相近，目标是在运算过程中不暴露数据明文。
- SAP HANA 隐私保护计算实验方案：部分企业级数据库系统（如SAP HANA）正在探索结合隐私保护技术，实现数据加密运算的实验性解决方案。

总的来说，全密态数据库目前仍处于技术探索和原型开发阶段，其在大规模商业部署和性能优化方面还需要进一步的研究和实践。但随着隐私保护技术的发展和数据安全需求的不断提升，未来全密态数据库有望在高安全性数据处理场景中发挥更大的作用。

在上述几种产品中，CryptDB 是一个典型例子，其通过多层加密（onion encryption）架构，实现了在服务端对密文数据进行排序或比较大小的计算，而不需要先解密整个数据。下面简要说明其实现原理：

CryptDB 的实现机制

分层加密（Onion Encryption）
CryptDB 采用了“洋葱式”加密思想，对每个敏感列采用多层加密。不同的加密层支持不同的查询操作，譬如：
- 同态加密层：支持加法或乘法等基本运算。
- 顺序加密层（OPE/ORE）：支持对加密数据直接做排序和范围比较。
当应用需要执行诸如排序或区间查询等操作时，CryptDB 可以将相关列“降解”到支持该操作的加密层，也就是使用顺序加密算法对数据进行包装，从而使得服务端能够在不解密真实数据的前提下直接比较密文的大小关系。
顺序加密（Order-Preserving/Order-Revealing Encryption）
在支持比较和排序的场景中，CryptDB 采用了顺序加密：
- Order-Preserving Encryption (OPE)：加密后得到的密文保持与明文相同的排序关系，即若 A < B，则加密后的 ciphertext(A) 也小于 ciphertext(B)。
- Order-Revealing Encryption (ORE)：密文本身可能不直接表现为有序形式，但通过特定算法可以透露密文之间的顺序关系。
这种设计使得数据库在执行 ORDER BY 或用于范围查询的 WHERE 条件时，可以直接操作密文，从而避免暴露明文信息。
加密层降级（Encryption “Peeling”）
CryptDB 根据查询语句的安全要求和计算需求动态决定使用哪一层加密：
- 对于要求较高安全性的查询，尽量保持密文层级不被降解。
- 当查询需要排序或比较时，可“降级”至支持顺序操作的加密层，通过多层设计来平衡安全性和功能性。

CryptDB 利用分层加密的方式，其中关键的实现技术是采用顺序加密（如 OPE/ORE），从而允许服务端直接对密文数据进行排序和比较操作，而无需对数据进行完全解密。这种设计在满足基本查询功能的同时，也为防止明文泄露提供了一定的保护，是目前在学术和原型系统中较为成熟的思路之一。

洋葱模型概述

CryptDB 利用“洋葱模型”对每一列数据进行分层加密，每一层都使用不同的加密算法，从而在保护数据机密性的同时，允许数据库在不解密数据的前提下对数据执行部分 SQL 操作。通过动态“剥洋葱”（peeling）的方式，系统在查询执行前将加密层逐步从外向内转换为适应查询操作的模式。这种设计既尽可能保证数据安全，又使得诸如等值查询、排序、范围查询和某些聚合计算成为可能。

各层加密的功能与实现

下面介绍典型的 CryptDB 洋葱模型的各个加密层，每一层实现了特定的功能。

内层：随机加密（RND）

功能：
- 提供最强的安全保护（语义安全性），使得每次加密即使是同一明文也产生不同的密文，从而不泄露任何信息。
- 不支持任何直接在密文上执行的计算（例如比较、加法等）。
实现方式：
- 使用标准对称加密算法（如 AES）配合随机初始化向量（IV），保证每次加密结果随机化。
- 存储在数据库中的最内层密文即使被窃取也无法直接得出任何数据属性。
特点与局限：
- 安全性极高，但无法直接对密文进行任何查询运算，因此必须在需要计算时通过外部组件转换成其他形式。

中间层：确定性加密（DET）

功能：
- 用于支持等值比较（例如 WHERE column = value）和连接操作（JOIN）。
- 该层的加密方式保证相同的明文总是映射为相同的密文，从而使得数据库能在密文层面上判断数据是否相等。
实现方式：
- 利用对称加密算法在确定性模式下（例如使用固定的初始向量或采用分组密码模式中的 ECB 模式，经过专门设计避免简单重放攻击），确保同一明文加密后结果一致。
- 数据在DB存储时，其外层可能仍然包裹了 DET 密文，而内层数据仍然是 RND 加密。通过“洋葱”设计，查询时可以由受信任的代理服务器（SQL proxy）选择性地剥离外层，将密文“降级”为 DET 层以支持匹配比较。
示例：
假设有员工表的 email 字段：
- 加密前："alice@example.com"
- RND 加密后：得到随机密文（不可重复）
- 如果需要对 email 执行等值查询，则在“洋葱”中使用 DET 层，此时相同的 email 会映射为相同密文，便于数据库执行 = 运算。

外层：顺序加密（OPE / ORE）

功能：
- 支持范围查询（例如 WHERE salary > 5000）和排序操作（ORDER BY salary）。
- 加密结果保留了明文之间的相对顺序，即如果明文 A 小于明文 B，那么在外层加密下，密文 A 依然小于密文 B。
实现方式：
- 实现上可使用 Order-Preserving Encryption（OPE）或者 Order-Revealing Encryption（ORE），前者直接产生有序密文，后者需要额外算法才能比较密文顺序。
- 在数据库执行范围和排序查询前，可信代理组件（SQL proxy）剥离最外层加密，将数据转为 OPE/ORE 模式，使得数据库可以在密文上直接执行数值比较而无需解密成明文。
示例：
对于员工 salary 字段：
- 明文：3500, 5000, 7200
- 初始存储时整个字段使用 RND/DET 包裹。
- 当执行诸如 SELECT * FROM employees WHERE salary > 5000 ORDER BY salary 的查询前，代理服务器将 salary 字段的加密层剥离至 OPE 层。
  在 OPE 模式下，数据库存储的密文例如可能为：
  - 对应 3500 → 密文 A
  - 对应 5000 → 密文 B
  - 对应 7200 → 密文 C
    并满足 A < B < C，从而可以直接用 ORDER BY 或 > 进行比较计算。

同态加密（用于加法或聚合计算）

功能：
- 支持某些聚合操作（例如求和、平均值），通常利用加法同态特性实现，而无需解密数据。
实现方式：
- 更典型的情况是在查询需要对数值进行加和或其他数学运算时，通过将加密数据保持在支持加法同态运算的加密算法（如 Paillier 加密）之下，实现密文直接计算，再由受信任组件对计算结果进行解密。
- CryptDB 设计中会根据查询需求动态判断是否需要从 DET/OPE 层再降级为支持加法同态的层次，不过这种转换会带来更高的计算开销。
示例：
假设需要计算某个部门所有员工薪资的总和：
- 通过同态加密加法运算，数据库直接对密文执行加法操作，而无须将每个薪资解密出来；
- 最终得到的密文总和由可信代理进行一次解密得到明文结果。

动态“剥洋葱”过程

CryptDB 的一个关键点在于查询“透明”地利用加密数据。具体流程如下：

初始状态：
每个敏感列数据按洋葱模型存储，即数据同时包裹了 RND、DET、OPE（以及可能的同态层）密文。
查询请求：
数据库接收到 SQL 查询，查询中包含某种操作（如等值匹配、范围查询或聚合计算）。
代理转化：
中间代理（trusted proxy / SQL proxy）解析查询，根据操作需求选择合适的加密层对数据进行“剥洋葱”操作，即将外层的加密转换为支持该操作的形式。例如：
- 求范围比较时，剥掉 RND/DET 层变为 OPE 层。
- 求等值比较时，剥掉外层直接使用 DET 层。
- 进行聚合计算时，将数据转换到支持加法同态的层次。
查询执行：
数据库对转换后的密文执行查询运算（排序、比较、加法运算等），所有操作均在加密状态下完成。
结果返回与解密：
查询结果返回到 SQL proxy，再由代理进行适当的解密（依赖用户密钥）后返回给最终用户。

总结与举例

以一个员工信息表为例，假设表中有 email（用于等值查询）、salary（既需范围比较又需聚合）的字段，CryptDB 的加密过程如下：

Email 字段：
- 初始使用 RND 确保机密性。
- 为支持等值查询，外加 DET 层。当用户查询 WHERE email = 'alice@example.com' 时，SQL proxy将 email 字段转换为 DET 状态，让数据库能直接比较密文。
Salary 字段：
- 初始全层采用 RND 加密保存原始数据。
- 内嵌 DET 层支持部分等值操作。
- 外部包裹 OPE 层支持范围查询和排序，例如查询 WHERE salary > 5000 ORDER BY salary 时，通过剥离外层获得可比较的 OPE 密文。
- 若执行聚合查询 SELECT SUM(salary)，则进一步转换到支持加法同态的层次，允许在密文上直接完成加法运算，最后由代理解密聚合结果。