Cassandra中的可搜索加密实现

Apache Cassandra中的可搜索加密

摘要

在当今的云计算应用程序中，客户端将其数据外包给云存储提供商是普遍做法。这些数据可能包含敏感信息，客户端希望在此不可信的环境中保护这些信息。通过使用加密可以保持机密性。然而，这使得高效搜索难以实现。

为了解决此问题，已提出了一些不同的方案，但其中仅有极少数方案在数据库服务器上得以实现和测试。传统数据库通常依赖于SQL模型，而近年来为了满足所谓“Web 2.0”在可用性和分区容忍性方面的新需求，出现了许多替代方案，统称为NoSQL（意为“不仅仅是SQL”）数据库。

本文在流行的NoSQL数据库Apache Cassandra（由多家云存储提供商提供）中实现了三种不同的加密数据搜索方法，并在分布式环境中进行了测试。此外，我们量化了它们的性能，并探讨了优化的可能性。

Keywords: 可搜索加密 · Benchmarking · Apache Cassandra

1 引言

由于每天产生的数据量不断增加以及Web2.0服务对高可用性、一致性和分区容忍性[1]的需求，同时要求在商用硬件上具备良好的可扩展性，工业界正转向分布式数据存储。运行在分布式云环境中的NoSQL数据库正是为满足这些需求而设计的。它们以低成本提供了易用性和灵活性，且用户无需担心数据存储和共享所消耗的资源。此外，云服务提供商通常提供可按需灵活配置的存储空间。

然而，将敏感数据外包给第三方存储提供商一直存在安全风险，无论是在私营部门（例如照片或健康信息的共享、消息传递）还是在企业部门（例如机密文件或保密邮件）。不仅对数据服务器具有物理访问权限的攻击者可能构成威胁，托管服务提供商中（诚实但）好奇或恶意的数据库管理员也可能窥探敏感数据。

从而构成威胁。NoSQL数据库通常不提供任何机制来确保其存储数据项的机密性。因此，这种安全功能的缺失常常阻碍了云存储的更广泛使用。

在不可信环境中，加密始终是一种便捷的应对措施。它可以确保对外部存储的数据记录进行非法读取访问时的机密性，但通常会对与加密数据的交互能力带来一些限制，尤其是在搜索方面。已经提出了多种对称可搜索加密方案以解决此问题[2]，但据我们所知，这些方案尚未在现有的云数据库技术中得到测试。因此，本文作出如下贡献：
– 我们实现了三种可搜索加密方案 [3–5]。
– 我们在一个由两个节点组成的分布式环境中量化了所有方案的性能。
– 此外，我们评估了它们在实际中的可用性，并讨论了性能优化。

2 Apache Cassandra

Apache Cassandra [6]既可被视为键值存储，也可被视为（宽）列族存储。其数据模型旨在表示Web 2.0中常见的松散结构化数据项。目前，它是该类别中最受欢迎的数据库¹。Cassandra基于严格的对称点对点概念，在分布式部署中使用Gossip协议进行协调。它利用本地文件系统，并在每个节点上以单个 Java进程运行。根据CAP定理[1,7]，Cassandra提供可用性和分区容忍性。

与大多数传统的基于SQL的关系型系统不同，Cassandra 不提供用户、角色或访问权限管理。前端需要根据需要提供此功能（例如，云存储接口）。以加密形式存储数据可以提供更高的安全级别，但 Cassandra 并未提供任何原生机制来实现这一点。

¹ SolidIT：DB‐Engines排名。http://db-engines.com/en/ranking，访问于2015年7月13日。

3 可搜索加密方案

本节简要概述了我们所使用的可搜索加密方案的不同思路：Curtmola等人提出的CGK方案[4]，Hahn和Kerschbaum提出的HK方案[5] ，以及Song等人提出的SWP方案[3]。由于本文篇幅有限，更多关于这些方案工作原理的详细信息请参阅原始论文。有关安全定义，请参见[2]。

3.1 CGK[4] ‐ 每个关键词的索引

Curtmola等人提出的方法在搜索时间方面非常有前景。该方法依赖于一个索引，该索引由一个数组 A组成，用于存储来自文档集 D包含唯一词的文档标识符列表，以及一个查找表 T，用于确定正在搜索的特定词在 A中的第一个元素。

该索引是针对文档集 D中的每个唯一词创建的，而不是按文档创建。CGK方案²是首个实现最优搜索时间的方案，生成的索引在每篇文档的不同词数量上呈线性增长。由于数据索引的方式，更新代价高，这使得该方案更适合“一次写入”型数据库。其非自适应版本提供IND‐CKA1（在选定关键词攻击下不可区分）安全性，自适应版本提供IND‐CKA2安全性。

² 本文中提到的CGK算法均指其“非自适应”版本。

3.2 HK[5] ‐ 每文档索引

同样满足 IND‐CKA2 安全性的 HK 算法使用两个索引： γf 和 γw。其核心思想是将每个文档中的所有唯一词（与 CGK 不同）以一种类似于 SWP 的特殊加密形式存储在前向索引 γf 中。此外，γw 是一个倒排索引，用于存储之前的搜索结果，以便在未来以常数时间提供查询结果。该加密过程所需的迭代次数等于每个文档中的唯一词数量。因此，根据给定的数据集，该过程可能非常快速。但从另一方面来看，这意味着该算法在设计上只能判断某个搜索词是否出现在文档中。

3.3 SWP[3] ‐ 顺序扫描

基于顺序扫描的SWP算法³在希望避免使用索引（例如出于实际原因）[2]时几乎是唯一的选择。其基本思想是对固定大小的词进行加密 n，并通过特定形式在密文中嵌入哈希值。搜索时再次提取该哈希值，如果该值具有特定形式，则表示匹配成功。SWP不需要任何状态信息，因此可立即用于加密或搜索，并且在许多场景中易于实现。与大多数基于索引的方案不同，它还能提供文档中匹配次数（和位置）的精确信息。但缺点是，作为典型的线性扫描算法，其加密和搜索耗时为线性时间，因此在大型数据集上可能非常耗时。SWP具有 IND‐CPA（在选定明文攻击下不可区分）安全性。

³ 本文中提到的SWP算法均指其 “最终方案”。

4 实现

我们使用 Java 8 实现了所有这三种方案。对于必要的密码学原语，我们采用了两个不同密码提供者的实现。Java密码学扩展（JCE）以及Bouncy Castle加密包（BC）⁴。如果两个安全提供者都支持所需功能，我们始终选择性能更快的一个。为了连接Apache Cassandra，我们使用了Java驱动2.1，并结合当前版本3的Cassandra查询语言（CQL）。

⁴ Bouncy Castle军团。 http://bouncycastle.org，访问于2015年7月13日。

5 基准测试

我们采用可搜索加密在邮箱数据中的流行应用场景。我们使用了TREC 2005垃圾邮件跟踪公共语料库⁵的一个子集。假设邮箱的平均大小从1,000封邮件到 10,000封邮件不等。因此，我们从语料库的前1,000封邮件开始进行测量，并逐步增加邮件数量至10,000封，以观察各方案和数据库的扩展性。在此过程中，明文单词的数量从大约70万增加到超过700万，其中约40%的单词在HK方案意义上是唯一的。请注意，邮件中的每个单词都计入统计，包括“a”、“the”、“in”等词汇。这意味着每个单词都可以进行搜索。

Cassandra 是一种键值存储，这意味着邮件文档必须以某种方式映射为键值格式。我们按如下方式实现：所有邮件都写入一个键空间中的单个表中。其中，邮件在数据集中的文件路径用作唯一键，加密后的邮件内容作为其值。当然，也可以采用更复杂的结构，例如将邮件拆分为发件人、收件人、正文等部分，并使用相应的额外键。但为了简化起见，我们采用这种基本格式，因为没有理由认为其他方式会对结果产生显著影响。

在我们的实验设置中，客户端连接到一个由两个节点组成的分布式Cassandra集群，每个节点配备Intel Core i7 3770 CPU（@ 3.4 GHz）和16GB内存，运行Ubuntu 14.04 LTS和Apache Cassandra 2.1.4。所有测量结果均包含由网络流量引起的时间。

5.1 加密

在我们的首次测试中，我们测量了加密过程所需的时间，其中包括将结果（加密文件本身以及必要时的查找表、索引等）输出到数据库所需的时间。

如图1所示，在所有方案中，加密所需时间呈线性增长。HK方案是最快的，SWP方案的速度也并未显著更慢。这两种方案的性能大约比CGK方案快4.5倍。

CGK方案创建 A链表数组的过程远比其他方案的加密步骤复杂得多。因此，SWP和HK方案能够实现每秒加密95,000到130,000个词，而CGK算法仅达到约每秒23,000个词，尽管如此，在实际应用中仍然可以接受。

⁵ 可访问 http://plg.uwaterloo.ca/∼gvcormac/trecspamtrack05，访问于2015年7月13日。

5.2 搜索

在我们的第二次测试中，我们测量了搜索单个单词所需的时间，因为这三种方案对于多个单词的搜索均无法提供优于简单“AND”组合的方法。为了使比较更加公平，我们对SWP方案进行了轻微修改，允许在文档中一旦发现首个匹配项即终止搜索，并继续下一个文档的搜索。这样，它提供的信息与其他方案相同，即判断文档是否包含所查找的单词。

图2展示了结果。CGK方案的高加密开销带来了亚线性搜索时间（在搜索 10,000封邮件时为0.13秒）。由于其索引 γw只有HK方案可以更快（恒定搜索时间），但仅在重复搜索同一单词时成立（HK2）。首次搜索某个单词时，其性能数量级更差（HK1）。此时它的速度几乎与SWP方案相当。请注意，即使在我们的测试中速度最慢的SWP方案，每秒仍能搜索超过五十万个词。

6 优化选项

在测试过程中，我们注意到所有方案在实际应用中都有优化空间，下面将简要描述这些优化。

CGK方案创建一个数组 A，用于存储每个不同单词的文档标识符列表。在创建索引时，如果对列表数量中的每个节点分别执行插入命令，将会显著影响构建索引所需时间的性能。为了优化这一点，我们采用了批量插入的方式将节点插入数据库，以减少与服务器的交互次数。对于我们的数据集，发现每次插入500个节点为最优值，与单次插入相比，性能提升近65%。

HK方案几乎不允许像先前方案那样在速度方面进行性能优化。实践中更可能出现的问题是 γf的索引大小。由于它可能变得相当大，因此一种防止其增长过快的解决方案是减少所用伪随机数生成器的输出长度（在原始工作中称为 G）。这样做会使存储在 γf中的加密表示更小，且不会带来安全问题。通过这种方式，我们使 γf的磁盘空间消耗最多减少了20%。

如前所述，SWP方案使用固定长度 n的单词，通过分割和/或填充原始明文单词来实现。由于该算法所需的迭代次数与待加密的单词数量相同，较大的 n可提升整体性能（所需迭代次数更少），而较小的 n可节省磁盘空间（所需填充更少）。针对我们的独立数据集，我们发现最优值为n ≥ 8，相比 n= 4速度快了35%。

7 相关工作

自从提出用于加密数据上顺序扫描的SWP [3]方案以来，已提出了许多变体。最近的一项调查[2]为比较不同方案提供了 excellent 的参考来源。主要区别在于所使用的对称与非对称原语。非对称可搜索加密（基于关键词搜索的公钥加密，简称“PEKS”）通常用于多个用户使用公钥写入加密数据，而只有持有私钥的单个读取者才能进行搜索的场景。然而，这比对称变体效率更低。

引入SWP方案的顺序扫描也已被用作CryptDB [8]中关系数据上的搜索功能。大多数后续方案采用基于索引的方法（除了测试的CGK和HK方案，例如[9–11]），因为该方法在处理大规模数据集时被证明是高效的，尽管索引大小可能变得过大而无法完全存储在内存中[12]（[12]还介绍了可搜索加密的实际实验和基准测试关系数据库）。然而，依赖索引并不总是可行的。构建和维护索引成本较高，特别是当数据集非常动态时。索引还需要某种适当的关键词分配。

8 结论与未来工作

我们实现了三种可搜索加密算法，分别是基于每个关键词建立索引的CGK方案、基于每个文档建立索引的HK方案，以及基于顺序扫描的SWP方案。这些方案使用Java实现，并以Apache Cassandra作为底层数据库。我们指出了这些方案在实际环境中的优缺点，并在分布式环境中对其性能进行了量化。此外，我们还讨论了优化策略。

CGK方案在加密时的速度约为每秒23,000词，不如其他方案快。HK方案最高可达每秒95,000词，而SWP方案甚至可达每秒130,000词，因此CGK方案慢了4到5倍。但结果表明，所有这些方案在实际应用程序中的实际应用似乎是可行的。搜索方面也类似，SWP方案每秒可处理多达530,000词，HK方案可达每秒660,000词。CGK方案昂贵的加密过程在搜索阶段得到了回报，在搜索过程中其速度比其他方案快8到10倍。

未来的工作可以通过多种方式扩展这些结果。一方面，需要支持数据库查询所需的其他功能。已有方法可以同时搜索多个关键词，但需要额外的数据结构[13,14]。诸如[15,16]之类的保序加密方案可用于范围扫描，以及管理时间戳和排序行键等数据库内部机制。因此，应尽可能使用Cassandra的用户自定义函数来实现加密功能，以确保在没有其他组件（例如前端）的环境中也能使用加密。然而，对于某些任务（例如查询重写），在应用程序和数据库之间使用代理客户端是不可避免的。另一方面，还需要在更大的集群中对更大的数据集进行测试。为此，我们计划在谷歌云平台或亚马逊EC2等流行的云计算平台上运行测试，这些平台提供了部署Apache Cassandra和其他NoSQL数据库的功能。