- 全密态数据库的功能和挑战其概述。
- 全密态数据库的应用个场景和3种典型架构。后续3章对3种架构的关键技术做总结和分析。
- 基于软件的加密方案。
- 基于可信硬件TEE的关键技术。
- 基于软硬融合的关键技术。
- 保护访问模式的相关技术的总结分析。
- 未来展望
全密态数据库概述
为敏感数据提供全生命周期的机密性保护：密态传输、密态存储、密态计算。
- 密态传输：使用TLS/SSL等技术，密文形式传输敏感数据。防止网络抓包、IP/DNS欺骗等传输过程中的泄露。
- 密态存储：密文形式存储在云数据库的磁盘上。防止存储介质上的泄露，如存储设备丢失或被盗、数据库文件泄露等。
- 密态计算：使敏感数据在云端非可信内存区域保持密文形式。防止拥有服务器超级权限的DBA窥探，以及黑客复制内存快照等手段攻击。
目前前两种技术相对简单比较成熟，很多云数据库厂商支持这两项功能。密态计算则复杂很多，是学术界和工业界近一二十年的热点。全密态数据库的关键技术主要在密态计算部分。
挑战主要包含安全性、高性能、功能性3个方面。
- 安全性。首要挑战，如果加密算法安全性较低，方案就不会被工业界采用。
- 高性能。现代数据需要支持海量数据和高并发、低延迟，有的软件加密方案（FHE）由于性能较低，没有可实践性，仅仅处于理论研究阶段。
- 功能性。数据库包含很多复杂运算（等值查询、范围查询、字符串查询、连接、聚集等），很多加密方案仅能支持其中一两项。
可时间的全密态数据库方案一般需要在三者之间做trade-off。
对于不同类型的数据库，如关系型和非关系型、事务型和分析型、集中式和分布式，不同类型数据库对全密态的技术需求有显著差异。通常全密态数据库应用于医疗、金融、政府领域，多属于关系型和事务型数据库，同时由于全密态计算的复杂性，目前主要集中在集中式数据库。
全密态数据库的模型和架构
系统模型
包含客户端和服务端两方。客户端的授权可信的，将数据外包给第三方不可相信云数据库服务端。敏感数据只在可信方以明文形式寸止，在发送给不可信方时，敏感数据被加密成密文形式，并在不可信方始终以密文形式存储和计算。
当客户端插入数据到服务端时，数据先被DB的客户端驱动程序加密成密文，具体哪些数据字段需要被加密，是由该数据所在表或集合的schema决定的。当客户端需要检索数据时，云服务端在密文上执行数据库运算（查询、连接、聚合等）并将查询结果以密文形式返回给客户端，客户端收到密文结果后，由驱动程序解密成明文。客户端驱动程序的加解密操作可以自动完成，因此对上层应用来说是透明的。
密钥服务用于密钥管理，为客户端驱动程序提供加密所需要的密钥。密钥需要两类：数据加密密钥DEK和用户主密钥（customer master key）CMK，用来加密DEK。加密后的DEK可以作为metadata存储在云数据库内。CMK是最敏感的数据，可以存储在用户本地或者可信的第三方密钥管理系统KMS，如AWS KMS、阿里云KMS等。不同字段可以使用不同DEK加密，通常在定义表或集合的时候指定需要加密的字段和加密的DEK ID，这些信息保存在表的metadata中。客户端驱动从metadata中读取这些配置从而完成自动加解密操作，客户端驱动程序向密钥仓库请求DEK，密钥仓库从云数据库取到DEK密文，用CMK解密后发送给客户端的驱动程序对数据进行加解密。
除了DEK和CMK之外，有的全密态数据库系统还设计了用户侧的设备密钥。
敌手模型
敌手分为被动型和主动型敌手两种类型。
- 被动型（passive）敌手又称诚实且好奇型（honest-but-curious），具有非法监听或读取数据的能力，无法篡改数据。对于这种类型的敌手，研究重点在于如何保护数据的机密性。
- 主动型（active）敌手又称恶意型（malicious），具有非法监听和读取数据以及篡改数据的能力。对于这种类型，不仅需要保护数据机密性，还需要对云端返回的数据做正确性和完整性校验。
3种典型架构
基于软件加密算法
运行在传统的非可信富执行环境（rich execution environment，REE）中，依赖纯软件的加密算法。挑战在于如何安全、高效地在密文上实现数据库操作。需要在安全性、功能性、性能之间做trade-off。
基于可信硬件TEE
依赖可信执行环境（trusted execution environment，TEE）实现密态操作。主流的TEE有Intel SGX等，阿里云的Enclage基于Intel SGX实现。TEE在云服务端开辟一小块可信区域，被称为飞地（enclave）。飞地可以看作客户端的一部分、客户端在云服务端 的延申。飞地是可信的，敏感数据在飞地内部可以是明文形式。通过远程认证（attestation）协议，TEE能够从客户端获取密钥，解密进入到飞地的密文数据，并在明文上执行各种数据库操作，再将结果加密，返回给客户端。
飞地的问题在于内存空间是有限的，而且TEE与REE之间通讯的上下文切换开开销高昂。将数据库集成到TEE、构架可信计算系统的挑战在于，首先，如何合理拆分DBMS功能，将哪些部分放到TEE执行，哪些部分放到REE执行；其次，对于需要放到TEE内的数据，如何设计合适的数据粒度、如何与REE交互；再次，如何减少TEE和REE的交互开销。
相比于上一种架构，TEE最大的有点是，由于数据在TEE内是明文状态，能够在明文上做各种数据库运算，因此功能性和性能都更好。目前工业界主流的全密态数据库大多都支持TEE的实现，如微软Azure、阿里云PolarDB、华为云GaussDB。TEE泄露信息更少，安全性更高，但十分依赖硬件厂商。近几年国内芯片厂商也推出了自主可控的TEE产品。
软硬结合
将部分查询操作利用加密算法和REE加密索引在REE下执行，部分操作利用可信硬件和TEE加密索引在TEE下执行。主要挑战在于如何正确选择和分配查询操作，以降低执行开销。GaussDB是典型代表。
基于加密算法的全密态数据库关键技术
这种架构仅依赖加密算法实现各种密文上的数据库操作，由于不依赖专用硬件，这类全密态数据库可以运行在一般的云主机上。但是这类数据库系统需要组合使用多种加密算法，来实现比较完整的数据库功能。
加密算法的安全性
1982年Goldwasser等人首次提出语义安全性（semantic security）的概念。对于一个加密算法，如果它的密文不会泄露明文的任何信息，或者根据密文来识别明文在概率上是可忽略的（negligible），则该加密算法是语义安全的。密码学家提出通过一种基于猜测游戏的安全性定义。敌手的限制条件的不同对应不同的安全登记。安全等级最高的是选择密文攻击下的不可区分性（IND-CCA）。很少有加密算法的安全等级达到IND-CCA，低一级的是选择明文攻击下的不可区分性（IND-CPA）。1984年Goldwasser等人证明IND-CPA安全性等价于语义安全性。随机加密算法的安全性为IND-CPA。
对于安全性达不到IND-CPA的加密算法，未来准确描述其安全性，通常会缩小限制条件。确定性加密的安全性为不同的选择明文攻击下的不可区分性（IND-DCPA）；保序加密的理想安全性为有序的选择明文攻击下的不可区分性（IND-OCPA）；对称可搜索加密的安全性为选择关键词攻击下的不可区分性（IND-CKA）。这三种安全性没有明显的高低可比性。
明文加密
工业界早期的全密态数据库仅能知识极少的密态操作，早期的MongoDB只支持明文加密，不能对密文做任何查询操作，需要通过非加密字段查询加密的数据字段。
明文加密通常采取随机加密算法（如随机初始化向量的AES-CBC），有较高的安全性，但是无法仅根据密文做任何查询操作。因此随机加密算法仅适合为安全性要求很高的敏感数据加密，通过非加密字段进行检索。
密态等值查询
基于确定性加密
确定性加密算法（如固定初始化向量的AES-CBC）将明文加密成确定的密文。因此确定性加密算法适合密态等值查询、等值连接、聚集等操作。但这样安全性较低，容易收到推理攻击，尤其是对于数据分布可能寸止规律的敏感数据（性别、年龄等）。
确定性加密算法仅适合安全性要求不高、统计信息不明显，有等值查询需求的敏感信息。很多工业界的全密态数据库早期使用确定性加密算法实现等值查询。
基于对称可搜索加密
可搜索加密（searchable encryption，SE）是密文搜索领域的研究重点，它使得数据拥有者（客户端）将敏感数据外包加密存储，并仍可以根据关键词检索加密的数据。广泛应用于医疗、政务、电子邮件等云服务场景。
- 插入数据时，客户端将数据加密成随机密文，同时为明文生成加密索引，将密文与加密索引发送给云服务端存储。
- 搜索某关键词时，客户端为该关键词生成陷门（trapdoor，也称为token），发送给服务端。
- 服务端基于陷门在加密索引上查找包含该关键词的加密数据，返回加密数据。
对称可搜索加密（SSE）是一个重要分支，使用对称加密算法加密敏感数据，性能上好于非对称可搜索加密（ASE）。此外，SSE适用于数据的拥有者和使用者为同一方的全密态数据库两方场景，而ASE适用于数据拥有者和使用者不是同一方的数据共享对方场景。2000年Song等人首次提出SE的概念，并提出了首个SSE方案SWP，具有IND-CPA安全性。但该方案没有生成加密索引，每次查询都需要完整遍历，效率较低。其他的SE方案都设计了加密索引，如倒排索引、正排索引、树形索引、布隆过滤器索引等。多种索引使SSE有广泛的适用性。正排索引和倒排索引的SSE支持密态等值查询；树形索引的SSE支持密态范围查询；布隆过滤器索引的SSE支持密态字符串通配符查询。
密态范围查询
基于分桶
2002年产生利用分桶的方法进行整数范围查询的加密方案。核心思想是将敏感属性的值域空间划分为若干个分区。插入数据时，客户端将每个元组整体加密，并为其中每个敏感属性值分配对应的桶ID，发送到服务端。查询时，查询条件中的常数会被替换成对应的桶ID。
分桶方案都基于确定性加密算法，将范围查询转换成多个桶的等值查询，是有效的查询方案。但是，同时也集成确定性加密的缺点，暴露了被查询数据的分区分布。此外，分桶方案都没有给出安全性定义和证明，从密码学角度来看，存在安全隐患。
基于保序加密
保序加密（order preserving encryption，OPE）使得密文保持了明文的顺序属性，并且明文和密文都是数字类型的数据。例如，若明文\(x \lt y\)，则对应密文\(OPE_K(x) \lt OPE_K(y)\)。对于数据库而言，这个特性使得可以直接基于密文构建B-树索引。但是OPE算法暴露了明文顺序，而且大部分OPE算法是确定性的，因此容易收到推理攻击，安全性较低。OPE的发展按照安全性来分，可以分成4个阶段。
- 无严格安全性定义的OPE方案。
- 有严格安全性定义的OPE方案。
- 理想安全性的OPE方案。
- 超越理想安全性的OPE方案。
基于揭序加密
揭序加密（order-revealing encryption，ORE）是对早期保序加密算法的改进。ORE密文通过比较函数来判断顺序（而OPE密文能直接判断顺序），ORE密文不需要只能是数字，此外ORE算法是无状态的、密文不改变、无需交互，但是ORE是确定性的加密算法，其密文没有隐藏相同明文的重复频率。
2015年Boneh等人首次提出ORE概念，该方案基于多线性映射达到了等价于IND-OCPA的安全性，但是效率很低。
虽然部分OPE和ORE方案除了顺序之外不会暴露任何明文有关信息，但是暴露顺序本身就会令安全性大大降低。比如，对于考试成绩或工资等具有分布规律的数据，攻击者可以通过密文顺序来观察分布规律，再结合公开的统计信息，推断出大量明文信息。
基于对称可搜索加密和树形索引
这种方案的核心思想是利用树形索引将范围查询转化为多个SSE token的等值查询。
通常使用树形索引表示一个值域（如32位非负整数），每个叶子节点代表值域的一个值，每个中间节点代表其所有下层节点的范围，根节点代表整个值域空间。
插入数据时，客户端生成随机密文，同时按照树形结构生成相关节点的加密索引值，发送到服务端存储。进行范围查询时，客户端按照树形结构将这个范围转换成多个相关节点的集合，生成对应的token集合，发送给服务端在加密索引里查找与token集合匹配的结果，返回给客户端。
与OPE和ORE相比，这种方案的密态范围查询安全性可以达到自适应选择关键词下的不可区分性（IND-CKA2）。功能性方面，这种方案集成进数据库需要大量适配开发，相对而言OPE和ORE对数据库密态查询非常友好；性能方面，树形索引的SSE密文空间膨胀较大。
密态字符串查询
字符串搜索包括：等值搜索、前缀搜索、后缀搜索、通配符搜索、模糊搜索等。密文的字符串等值搜索可以使用其他数据类型的等值搜索实现，前缀和后缀搜索是可以视作通配符搜索的特殊形式，因此密态字符串搜索可以归纳为两种类型：密文字符串通配符搜索和密文字符串模糊搜索。现有的方案多为加密文档的检索，在数据库场景下，可以将加密的数据字段作为加密文档，将这些方案应用中密态数据库场景中。
密文字符串通配符搜索
字符串通配符通常有两种：“?”代表单个任意字符，“*”代表多个字符早期的方案多为枚举形式，将所有可能形式进行枚举，因此效率低、存储量大。为解决这个问题，提出了基于SSE和布隆过滤器（Bloom filter，BF）的特征提取方案。BF是一种基于哈希的概率数据结构，可以高效地将元素哈希值添加到集合中，并测试集合是否包含某个元素。
基于SSE和BF的特征提取方案可以实现对密文的灵活通配符搜索，但是安全性不能达到SSE的IND-CKA。许多研究在探索安全性更高的方案。一些方案在增加安全性的同时，也增大了存储容量和降低了搜索效率。
密态字符串模糊搜索
模糊搜索（fuzzy search）可以找到与关键词类似或相关的结果。常见的明文模糊匹配算法包括编辑距离、N-gram算法、Soundex算法等。
早期的密文字符串模糊搜索方案的主要思路是基于编辑距离为搜索关键词构造模糊关键词集，之后提出了多个基于局部敏感哈希（locality sensitive hashing，LSH）的模糊搜索方案。
密态算数运算
半同态加密（partially homomorphic encryption，PHE）支持基于密文做指定的算数运算，可以用于执行安全的数据库聚集操作，如求和、均值、最大最小值等。
按照底层加密算法类型的不同，PHE可分为两大类：
- 基于非对称加密的PHE。1985年提出ElGamal方案和1999年提出Paillier方案，都是非对称的概率加密方案，且都满足语义安全性。ElGammal支持密文同态乘除，Paillier支持密文同态加减、密文与明文加减和乘法。
- 基于对称加密的PHE。基于对称加密的PHE方案是为了改进运算效率提出的。1026年提出仅支持同态加法运算的ASHE方案，采用对称加密来加快运算，并达到语义安全性。2020年Savvides等提出了支持同态加减的SAHE方案和支持同态乘除的SMHE方案，并给出了支持这两个方案的原型实现Symmetria，据称此方案的平均运算速度比传统的基于非对称加密的PHE快七倍。
此外，还有一些研究对已有的PHE做性能优化。
通用加密方案
上面介绍的加密方案都只能支持部分密态查询，还存在两种通用的加密方案：全同态加密（FHE）和混淆电路（garbled circuit，GC）。理论上这两种方案支持任何密文计算，从而可以支持任何密态数据库运算。
全同态加密
FHE方案是可以支持任何类型运算的同态加密方案，直到2009年才由Gentry提出第一个理论可行的FHE方案。之后在此方案的启发下，各类FHE方案开始涌现，整体发展可以归纳为在保障安全性的前提下，改进FHE的性能使之实际可行。
目前，和传统加密算法相比，FHE的时间开销和存储开销仍然极高。有研究对2个经典的FHE开源库进行性能测试，结果表明FHE加法效率比明文计算慢10万倍到100万倍，乘法比明文计算慢1000万倍以上。
混淆电路
GC最早用于解决百万富翁类的多方安全计算问题。理论上可以支持任何类型的密态运算，并且是语义安全的。但是为了保证安全性，执行过一次后需要重构。因此GC方案需要大量的计算、带宽和交互，性能较低。
百万富翁问题，由姚期智提出，形式化描述为：对两个秘密输入\(i\)和\(j\)，在不让任何第三方参与、不向对方泄露各自数值的情况下，比较\(i\)和\(j\)的大小（即判断函数值\(f(i,j)=i-j\)与\(0\)的大小关系）。
基于软件加密算法的全密态数据库系统
基于可信硬件TEE的全密态数据库关键技术
可信执行环境TEE是一种基于可信硬件的安全技术，使得敏感数据的计算可以被拆分到TEE中执行，而其余非敏感数据的计算在传统的不受信任的富执行环境（rich execution environment，REE）中运行，避免攻击者的恶意擦欧总或云主机管理员的窥探。目前，Intel SGX是全密态数据库中使用最广泛的TEE。
TEE提供一个称为飞地（enclave）的可信代码和数据区域，并向应用进程、操作系统和系统管理员隐藏了飞地内部的运算和状态，以在不可信的云主机进程中执行可信运算。TEE实现3个主要功能：
- 隔离（isolation），保护飞地内代码和数据不会被外部进程读取或修改。
- 密封（sealing），发送到飞地外的数据都被加密和验证。
- 认证（attestation），使用专用的签名密钥和指令生成不可伪造的认证结果，保障飞地内的代码和数据，在飞地内部执行的计算输出都是可信的。
以Intel SGX为例，飞地是进程中一个独立的地址空间，代码和数据存储在被保护的内存页面中（称为飞地页面缓存enclave page caches，EPC）。EPC中的数据由内存加密引擎MEE加密，并在EPC中始终保持密文状态，只有被加载到CPU缓存中的数据才能被解密。
应用与挑战
借助认证协议，客户端可以将解密密钥安全地传递给TEE。解密后的明文始终在飞地内，在其中完成运算，TEE保证其不会被窥探和篡改。根据功能需要的不同，运算结果可以明文形式返回给REE（例如服务端需要比较大小的结果来构建密文的B-树索引），也可以在飞地内加密后再返回给REE（例如加密列的求和结果）。
由于基于TEE的全密态数据库是借助飞地在明文上完成运算，因此理论上可以支持任何数据库操作，功能性上远由于上一章节讨论的技术。不过，TEE应用中数据库中存在一些挑战。
数据库功能在TEE与REE之间的拆分
按照放入TEE enclave的数据库模块，可以有3种设计模式：
- 整个数据库放入TEE。相当于以内存数据库的形式运行。此时TEE中代码不能直接访问I/O，会出现大量的TEE与REE之间的I/O交互，性能会下降。此外，这种模式会带来安全隐患，如SQL注入攻击等。
- 部分执行器放入TEE。将处理密文数据所需的部分DBMS模块放入TEE。
- 算子放入TEE。仅将算子（operator）放入TEE，如比较、加减乘除等。加密数据在TEE内解密成明文，并基于明文执行指定的运算，计算结果返回给REE中的DBMS模块。目前大多数全密态数据库选择此模式，如Always Encrypted、GaussDB等。
数据的加密粒度
加密粒度越大，泄露的信息越少，存储开销越小，利于批量处理，但集成的成本高，读些不够灵活（即使只读取一个基础的数据项，都需要将整个粒度的数据加载到enclave中）；加密粒度越小则相反。
大多数全密态数据库对基本数据对象进行加密，如元组、单元（cell）、索引值等。
有限的enclave内存
2015年第一代Intel SGX的enclave内存在启动加载时静态分配，大小只有固定的128MB。2021年第二代SGX引入enclave动态内存管理（EDMM），大大增加了enclave内存容量，极大地缓解了enclave内存不足的问题。
TEE与REE交互的巨大开销
由于交互开销成本巨大，在处理数据库查询时，如何减少交互次数和交互数据量，是一项持续挑战。
基于TEE的全密态数据库
软硬结合的全密态数据库
这种全密态数据库融合了栓双方的有点，部分查询操作利用加密算法和REE加密索引在REE下执行，部分操作利用可信硬件和TEE加密索引在TEE下执行，显著降低REE和TEE的交互开销。这种架构的主要挑战在于如何正确地选择和分配REE和TEE中的查询操作，以降低执行开销。
GaussDB是典型代表。它提供了两个执行模式，基于REE的软件执行模式和基于TEE的可信硬件执行模式，数据库系统会根据查询的功能划分和代价估计，自适应地选择执行模式。敏感数据在GaussDB中以列为单位加密存储在服务端，列加密的密钥也被加密后存储在服务端。
GaussDB的密钥体系分为3层：
- 列加密密钥（column encryption key，CEK）。对列属性的不同数据进行随机加密，通过随机初始向量保证各属性之间的加密隔离，某个CEK泄露只会影响到与之相关的属性。
- 用户主密钥（client master key，CMK）。不同用户使用自己唯一的CMK来加密自己的CEK，CMK永远不会离开用户的可信环境。
- 设备密钥（device key，DK）。不同的DK用于保护不同的CMK，实现用户侧客户端设备之间的加密隔离，进一步提升整体安全性。
全密态数据库的访问模式保护关键技术
加密对敏感数据的机密性提供了一定的保护，但是攻击者还能够通过分析访问模式（access pattern）推断出部分重要信息。访问模式是指访问的类型（读/写），以及被访问的内存地址或查询的返回结果。
基于软件
保护访问模式要求数据以不经意的（oblivious）方式被访问，让攻击者不能区分客户端的访问类型和被访问的数据。不经意随机访问机（oblivious RAM，ORAM）是研究的最广泛的一类不经意访问方案。
利用不经意访问的技术，全密态数据库在保护访问模式方面的研究可以分为几类：
- 保护连接操作的访问模式。
- 保护聚集操作的访问模式。
- 保护范围查询的访问模式。
基于可信硬件TEE
由于不经意访问的开销极高，基于软件的访问模式保护通常只能保护某个特定操作。可信硬件TEE使得通用型的访问模式保护成为可能。
全密态数据库关键技术的未来研究方向和挑战
基于软件算法
这类全密态数据库的优点在于不需要依赖指定硬件，可以在一般的云主机上运行，通用性较好。但是现有的加密方案都不受全密态数据库的最优解决方案，缺点在于安全性不够，或空间占用率高、计算开销大，或支持的数据库操作也有限。因此，需要设计更好的加密方案，在这些需求面前取得平衡。
目前，具有可实践性的加密方案大多只支持部分运算，导致基于纯软件的全密态数据库需要使用多个加密方案，这样既增加了设计和开发的难度，也增加了存储和计算的开销。如何让通用的加密方案（如FHE）具有可实践性，是重要目标。
对称可搜索加密SSE具有相对较好的安全性和功能性，但是密文空间膨胀较高，存储开销大，因此，如何降低其存储开销是一项复杂挑战。
半同态加密PHE可以有效支持数据库聚合运算，但效率不高。提升PHE的效率仍是研究方向。
此外，随着数据库处理的数据量越来越大，集群数据库与分布式数据库已成为主流。但是，有的加密方案不利于非单机的应用场景，如基于索引的SSE，索引大多集中存储。如何让这类加密方案适用于分布式的场景，是一项挑战。
基于可信硬件TEE
现有的基于TEE的全密态数据库大多是在传统数据库的基础上修改得到的。除了前文所述的挑战之外，如何基于TEE的特性，实现一个TEE原生的全密态数据库将是一项挑战。
软硬结合
现有的软硬结合的解决方案，软件和硬件部分是独立运算的，没有相互补充。如何利用REE和TEE各自的优势来协同查处理查询是一个挑战。此外，现有的软件部分加密算法大多基于确定性加密，安全性仍需要提高。
访问模式保护
不经意访问技术经过多年发展，性能仍然较低，通用的访问模式保护仍应用在研究型的全密态数据库中，而工业界的数据库对访问模式保护的仍然很少。长期的挑战在于，如何提高不经意访问方案的效率，使之具有可实践性。
标签：加密,综述,数据库,TEE,密态,密文,全密态,加密算法 From： https://www.cnblogs.com/louistang0524/p/18246529