云环境中加密数据保护技术

基于加密的实用技术在云环境中保护和管理数据

萨布丽娜·德·卡皮塔尼·迪维梅尔卡蒂、萨拉·福雷西、乔瓦尼·利夫拉加和皮耶兰杰拉·萨马拉蒂(B)
意大利米兰大学，意大利克雷马26013， sabrina.decapitani,sara.foresti,giovanni.livraga, pierangela.samarati@unimi.it

1 引言

信息与通信技术（ICT）的快速发展推动了基于公共云（例如微软Azure和亚马逊S3）的存储服务的发展和使用。因此，用户和企业纷纷将其数据迁移到云上，从而以相对较低的成本享受数据和服务的可用性、可扩展性以及可靠性等诸多优势。尽管毫无疑问，使用云服务带来了诸多好处，但由外部云服务提供商进行的数据存储和管理也引入了新的安全和隐私风险，这可能会减缓或影响云服务的广泛接受（例如，[29,47,49,65]）。一个主要问题在于，当数据所有者将数据迁移到云中时，他们失去了对数据的控制，而云环境并不在数据所有者的直接掌控之下，因而可能并非完全可信。这就意味着有必要保护存储或处理于云中的数据的机密性和完整性保障，以及对这些数据访问的安全性。近年来，研究和开发领域已关注这些问题，并设计出新型技术以确保云环境中的适当数据保护。在云中实现数据保护需要确保数据的机密性、完整性和可用性[36,48,63]。机密性意味着数据只能由被授权的各方访问和知晓。保证机密性需要保护：外部存储的数据；用户的身份和/或个人身份信息访问数据；以及用户对数据执行的操作。完整性意味着数据应受到保护，防止未经授权或不当的修改。保证完整性需要确保以下方面的真实性：在云中交互的主体、存储和维护在云服务提供商处的数据、查询和计算返回的响应。可用性意味着数据应在用户请求时可用，并且云服务提供商应满足数据所有者/用户与云服务提供商之间签订的服务等级协议（SLA）中规定的要求。保证可用性需要向数据所有者和用户提供所需的服务，并使他们能够评估SLA的履行情况。

密码学是可用于解决此类机密性、完整性和可用性问题并提高云服务用户信心的关键技术之一。密码学已从一门古老的科学——主要致力于秘密书写代码的设计——发展为现代密码学这一科学学科，提供了应对广泛安全问题的技术。过去，密码学技术主要用于保护通信（传输中数据），而如今它们也被用于保护静态数据和使用中数据（例如，[5,11,44]）。静态数据记录在存储设备（例如硬盘驱动器）上，可能在很长一段时间内都具有价值。使用中数据则由应用程序处理，以响应查询或执行计算。本章将讨论与云环境中静态数据和使用中数据保护相关的某些安全问题。我们分析了密码学技术在解决这些问题中的作用，特别是在这些技术与其他解决方案结合使用以增强保护保障和/或降低计算开销时的作用，从而使这些技术在实践中得以应用。 展示了参考场景：数据所有者将其数据集合外包给云服务提供商，不同用户通过其客户端访问这些数据。该场景具有以下关键安全挑战，本章后续部分将对此进行覆盖。

– 存储安全：存储在云中的数据应受到保护，防止未经授权的访问，即使存储服务提供商也无法访问（机密性），授权用户可访问（可用性），并且数据正确无误（完整性）。– 选择性访问：存储在云中的数据应根据数据所有者定义的访问控制策略，由用户按需进行选择性访问。–细粒度访问：加密的外包数据应用于细粒度检索和查询执行。– 查询机密性：对数据的访问目标应保持私密。– 查询完整性：查询和计算的结果应正确、完整且新鲜。

请注意，密码学技术在保护云环境中传输中数据方面也具有重要作用，其中数据经常在云服务提供商之间或云系统内部组件之间传输。在这些情况下，可以应用经典解决方案（例如虚拟专用网络和安全套接层），因此我们不再进一步讨论它们。

本章其余部分组织如下。第2节描述了云中数据安全存储的解决方案。第3节介绍了一些

2 数据存储保护

当数据由外部云服务提供商存储和管理时，其机密性、完整性和可用性变得至关重要。在本节中，我们阐述了密码学技术在确保这些属性方面的作用。为简化讨论，我们假设外包数据以关系型数据库的形式组织。但我们指出，所介绍的所有方法均可轻松适配于其他数据模型。

2.1 数据机密性

当数据集合被外包给云服务提供商时，其所有者将失去对数据本身的控制，因此必须对数据进行适当保护。自数据库即服务（DAS）范式[64]提出以来，如何在将数据外包给外部服务提供商时保护数据的问题一直受到研究界的关注。

为保护数据机密性，已提出多种方法，通常依赖数据加密[64]，使不了解加密密钥的主体无法理解数据内容。

目前，针对外包给云服务提供商的数据加密，存在两种不同的方法：(1) 加密由服务提供商自身管理，因此服务提供商使用其知晓的密钥对数据进行加密；(2)数据在发送给云服务提供商之前即被加密，而云服务提供商不知道加密密钥。尽管第一种方法能够实现更强大的功能

由于数据可以由服务提供商轻松操作和管理，从而降低数据所有者的开销，但这同时也意味着向服务提供商授予了对数据的完全访问权限。然而，在许多场景下，用户可能并不完全信任云服务提供商，而选择这些提供商可能是基于安全以外的因素（例如经济原因）。为了全面保护数据机密性，通常在外包数据之前应用加密，以便同时防范云服务提供商对数据的访问。

数据加密可以采用对称加密或非对称加密方案。许多方案采用对称加密，因为其成本低于非对称加密[64]。无论选择何种加密方案，都可以在不同的粒度级别上对数据进行加密：单元格级（每个单元格单独加密）、元组级（关系中的一个元组内所有单元格一起加密）、属性级（关系中某一列的所有单元格一起加密）或关系级（整个关系作为单个数据块进行加密）。尽管加密操作的粒度级别不会影响数据机密性，但大多数现有方法采用元组级加密，因为它能更好地支持云服务提供商处的查询评估（参见第4节）4。事实上，关系级和属性级加密需要将整个关系或查询所涉及的属性子集传送给发起查询的客户端，而无法在服务提供商端过滤掉不相关的加密元组。另一方面，单元格级加密会给数据所有者和客户端带来过高的加解密工作负载。因此，元组级加密在客户端和数据所有者的加解密工作负载与查询执行效率之间提供了良好的权衡[64]。

采用元组级加密，定义在关系模式R(a1, . . . , an)上的关系 r在云服务提供商处表示为加密关系rk ，其模式为 Rk(tid, enc)，其中tid是添加到加密关系中的主键，enc是加密的元组。每个 ri中的元组 t在 rk中表示为加密元组 tk， 其中 tk[tid]是一个随机标识符，tk[enc]=Ek(t)是加密的元组内容， E是对称加密函数，密钥为 k.。 一个关系（a）及其对应的加密版本（b）的示例)展示了存储某医院八名患者医疗信息的关系 MedicalData， 一个关系（a）及其对应的加密版本（b）的示例)展示了相应的加密关系。

使用加密来保护数据机密性是基于以下基本假设：所有数据的敏感程度相同，因此需要通过加密来保护它们。然而，在某些场景下，这种假设可能过于严格，因为数据本身可能并不敏感，真正敏感的是它们之间的关联（例如，图 2(a) 中的患者姓名列表及其疾病列表本身可能不敏感，但每个患者姓名与其所患疾病之间的关联应当受到保护）。在这些场景中，可将加密与数据碎片化相结合，以保护属性值之间的敏感关联[9,11]。碎片化是指将关系 R中的属性集合垂直分区为不同的（垂直）片段，使得构成敏感关联的属性被分散到不同片段中，并且敏感属性可能被模糊化（例如，对敏感属性进行加密或不发布）。

人们提出了不同的解决方案来定义能够最小化查询评估成本的正确分片（例如， [10,11,18]）。

2.2 数据完整性与可用性

数据完整性和可用性是在外部云服务提供商处存储数据时应确保的两个关键要素。数据完整性意味着云服务提供商或未授权方无法在不被检测到的情况下不当篡改存储中的数据。与机密性类似，提供数据完整性的技术也可以在不同的粒度级别上运行：单元格、属性、元组或关系级别。然而，在关系级别或属性级别验证完整性需要在每次完整性检查时访问整个关系（或相应的列）。另一方面，在单元格级别进行完整性验证会对客户端造成相当大的开销。为了在完整性保障和客户端额外开销之间找到良好的权衡，大多数现有方案在元组级别上运行。下文将介绍一些用于确保数据完整性和可用性的最知名（基于加密的）技术。

数字签名和聚合签名。 数据完整性可以通过数字签名（例如，[44]）来确保。每个数据所有者拥有自己的一对〈私钥密钥，公钥〉。每个元组首先使用其所有者的私钥进行签名。然后将该签名与实际的元组连接在一起，此连接后的数据块被加密并发送给云服务提供商进行存储。通过检查与元组相关联的签名，可以立即检测到对元组的未经授权的修改。这种基本方法虽然有效，但缺点是完整性验证的成本随着访问的元组数量线性增长。

为了减轻这一负担，可以通过采用压缩RSA、BGLS或批处理DSA签名聚合[55]，将与多个元组相关的多个数字签名合并为单个签名。压缩RSA是传统 RSA加密方案的扩展，允许合并生成的签名由同一签名者（即与同一所有者的元组相关联的签名）生成的。BGLS [6]是一种基于双线性映射的加密方案，支持对不同签名者生成的签名进行聚合（即当签名由不同所有者生成时）。批量DSA是传统DSA签名方案的扩展，允许组合不同元组的签名，并可一起验证。批量DSA签名聚合的验证基于这些签名的乘法同态性质。压缩RSA和BGLS方案的签名验证过程比批量DSA的验证过程更高效。然而，压缩RSA和BGLS都是可变的，这意味着掌握多个聚合签名可以将其组合，从而获得一个有效的签名，该签名可能对应于任意元组集合的聚合签名。这可能对云数据集合的完整性保障构成威胁。

POR-PDP。 加密也是可检索性证明（POR [50]）和可证明数据持有（PDP [4]）方案的基础，这些方案旨在确保数据完整性和可用性。这些技术允许一个验证者（例如请求客户端或数据所有者）获得证明，以确认存储云服务提供商正在正确维护相关资源（确保其完整性），并因此能够正确地返回该资源（确保其可用性）。POR与PDP之间的主要区别在于获取证明的机制。POR基于在数据集合外包之前由数据所有者插入特定的随机哨兵，并通过加密层使其与真实数据无法区分。在验证步骤中，验证者通过请求某些哨兵值来挑战服务提供商。如果数据集合被服务提供商或未授权方篡改，则这些值将以不可忽略的概率出现错误，从而表明数据完整性和可用性均已被破坏。这一基本技术已在多个方向上得到扩展，以生成紧凑证明并返回给数据所有者（或任意验证者）[68]。

PDP基于特定的同态可验证标签。数据所有者预先计算与其集合中数据项相关联的一组标签，将标签与数据集合结合后存储于云服务提供商处。在验证步骤中，客户端针对随机选择的数据项向服务提供商发起挑战。服务提供商随后利用所请求的数据及其对应的标签，生成所需数据项的持有证明，客户端可轻松验证该证明。值得注意的是，由于标签具有同态性质，为多个数据项计算的标签可以合并为单个值[4]。我们注意到，POR的安全性依赖于云服务提供商无法识别哨兵，因此只能用于保证加密数据集的完整性。相反，PDP更具灵活性，可用于加密和明文数据集。

审计。 上述方法要求客户端自行检查所关注资源的完整性。为了减轻客户端的负担，在某些场景下，可能希望将验证过程委托出去

给一个第三方，该第三方被信任以执行完整性检查并访问数据内容。文献[74]中的解决方案依赖于一个可信审计员的存在，该审计员负责评估存储在云服务提供商处的数据集合的完整性。如果审计员不可信，无法访问外包数据集，则可以采用特定技术（例如同态线性认证器和随机掩码）。[74]另一种基于公开审计的解决方案已在[86],中提出，旨在提升审计过程的性能。

3 选择性访问数据

数据所有者将他们的数据外包到云中时，可能希望有选择地向其他用户公开或允许访问这些数据。此类功能需要访问控制的支持，以正确执行数据所有者定义的授权（例如，[16,24,30,37]）。在云环境中，由于性能原因，数据所有者和由于安全原因，云服务提供商均无法强制执行此类授权。解决此问题的一个有前景的方向是使外包的数据自我执行访问限制[14,20,21]。在本节中，我们介绍两种专门设计用于在外包数据上实施访问控制的方法：选择性加密（第 3.1节）和基于属性的加密（第3.2节）。

3.1 选择性加密

选择性加密是指使用不同的密钥加密不同的元组，并有选择性地将这些密钥分发给授权用户，使得每个用户只能解密其被授权访问的所有且仅限于这些元组。

基本技术。 授权策略规定了系统用户集合 U 中的哪些用户可以读取关系 r中的哪些元组，该策略可表示为一个访问矩阵 M，其中每一行对应每个用户 u∈U，每一列对应每个元组 t∈r，满足： M[u,t]=1当且仅当 u可以访问 t；否则 M[u,t]=0 。访问矩阵的第 j th列表示元组 acl的访问控制列表tj（tj），其中 j= 1，⋯， |r| （即可以访问该元组的用户集合）。展示了对 一个关系（a）及其对应的加密版本（b）的示例)中关系MedicalData的元组进行访问控制的访问矩阵示例，涉及用户 A、 B、 C和 D。根据该访问矩阵， acl（t1）=AC。

使用加密来实施访问控制策略需要为加密资源建立密钥，并将密钥分发给用户。加密策略与访问控制策略之间的等价性要求每个用户只能解密其根据访问控制策略有权访问的所有且仅有的元组。

将访问控制策略转换为等效的加密策略有多种方式。然而，这种转换应考虑两个主要的期望特性[21]：(i)每个用户只需管理一个密钥；以及(ii)每个元组只能用一个密钥进行加密（即，不复制任何元组）。这两个期望特性旨在减少用户端产生的开销

通过密钥管理，以及数据复制通常引发的一致性问题。为了满足这两个约束，选择性加密方法依赖于密钥派生技术，该技术允许从另一个密钥 ki和一段公开可用信息出发计算出一个加密密钥 kj。这些技术基于定义一个密钥派生层次结构，该结构可以用有向图直观表示：系统中每个密钥 ki对应一个顶点 vi，当且仅当密钥 ki可直接导出密钥 kj时，存在一条从密钥 ki到密钥 kj的边(vi,vj)。密钥派生可以递归应用，即只要在密钥派生层次结构中存在一条从顶点vi到顶点 vj的任意长度路径，就可以从密钥 ki推导出通用密钥 kj。根据密钥派生层次结构的类型，可采用不同的密钥派生技术，如下所述。

– 顶点链 （例如，[66]）：与顶点 vj 关联的密钥kj 通过将单向函数应用于链中前驱顶点 vi 关联的密钥 ki 来计算。推导密钥时不需要任何公开信息。
– 树形层次结构 （例如，[67]）：与顶点 vj 关联的密钥 kj 通过将单向函数应用于其直接祖先节点的密钥 ki 和与 kj关联的公共标签 lj 来计算。公共标签是必要的，以确保树中同一节点的不同子节点具有不同的密钥。
– DAG层次结构 （例如，[2]）：层次结构中的顶点可以有多个直接祖先，且层次结构中的每条边都关联一个公共令牌[3]。给定两个分别与顶点 vi 和 vj 关联的密钥 ki 和 kj，使得(vi,vj)是DAG中的一条边，并且已知 kj的公共标签 lj，则可通过令牌ti,j 从 ki 和 lj计算出 kj 。令牌ti,j 的计算方式为ti,j=kj⊕f(ki,lj)，其中 ⊕ 是按位 xor 操作符， f 是一个确定性密码函数。通过使用ti, j，所有知道或能够推导出密钥 ki 的用户也可以推导出密钥 kj。

可以根据上述任一模型定义密钥派生层次结构。接下来，我们考虑有向无环图（DAG）的最一般情况，并采用基于令牌的密钥派生[21]。

读取权限的实施。 定义密钥派生层次结构以执行访问控制策略的一种直接方法是为用户集合 U中的每个子集在层次结构中插入一个顶点，并利用这些子集之间的集合包含关系 ⊆来连接顶点。对于一对顶点 vi和 v j ，当且仅当从 vi到 v j存在一条路径时，其所表示的用户集合之间满足包含关系

由 vi表示的集合是 vj所表示集合的一个子集。例如，展示了由用户集合 U={A,B,C,D}及其上的集合包含关系所诱导出的密钥派生层次结构。在图中，顶点以它们所代表的用户集合作为标签。该层次结构所诱导出的加密策略当且仅当满足以下两个条件时，才等价于（从而正确实施）授权策略：(i) 每个用户ui被提供与其所代表顶点相关联的密钥；以及(ii) 每个元组 tj使用代表 acl(tj)的顶点的密钥进行加密。这些加密和密钥分发策略保证了每个元组只能被其访问控制列表中的用户解密，且每个用户只需管理一个密钥，每个元组也仅用一个密钥加密。参考中的密钥派生层次结构以及和中的访问控制策略，展示了分配给用户的密钥以及用于加密中关系 MedicalData内元组的密钥。注意，中的加密策略等价于中的授权策略，因为每个用户可以从自己的密钥推导出代表包含她的用户集合的顶点的密钥，从而能够解密她被授权读取的元组。例如，用户 C可以推导出用于加密元组 t1和 t7的密钥。

在正确实施给定的授权策略的同时，上述所示的加密策略定义了比必要数量更多的密钥和令牌。管理大量令牌会降低推导过程的效率，并最终增加对用户的响应时间。事实上，令牌存储在由服务提供商维护的公共目录中：当用户 u想要访问元组 t时，她需要在目录中进行搜索，以检索一条令牌链，该令牌链从她自己的密钥开始，最终到达用于加密 t的密钥。因此，令牌的总数是影响远程存储数据访问效率的关键因素。在保证授权策略与加密策略之间等价性的前提下，最小化密钥派生层次结构中令牌数量的问题属于NP难问题，因为它可以归约为集合覆盖问题[21]。在[21],中，作者提出了一种基于以下两个观察结果的启发式方法来减少令牌数量。

AB
AC
AD
	BD

A
A
B
C
	D

ACD

用户密钥
A B C	kA kB kC
D	kD

元组密钥
t1 t2 t3 t4 t5 t6 t7 t8	kAC kBD kAD kB kAB kB kACD kD

(b) (a)

– 为实施授权策略所需的顶点是那些表示用户单元素集合的顶点（其密钥会传达给用户）以及 r中元组的访问控制列表（其密钥用于加密），这些顶点称为 material；– 当两个或多个顶点具有两个以上的共同直接祖先时，插入一个表示这些祖先中用户集合的顶点可减少令牌总数。

给定一个授权策略，该启发式方法首先识别物化顶点，并针对每个顶点 v， 找到一组构成非冗余覆盖的物化顶点（即最小顶点集合 V，使得对于由 v表示的每个用户 u ，在 V中至少存在一个顶点 vi，使得 u出现在 vi中），这些顶点成为 v的直接祖先。对于具有共同祖先 v′ 1，…， v′ n的每组顶点 n> 2，算法插入一个中间顶点 v，用以表示 v′ 1，…， v′ n中的所有用户，将每个 v′ i，i= 1，…，n与 v相连，并将 v与每个 vj， j= 1，…， m相连。通过这种方式，加密策略在目录[21]中包含 n+ m，而不是 n · m个令牌。展示了一个与中的授权策略等效但令牌数量减少的加密策略。比较和中的密钥派生层次结构，可以明显看出正确实施访问控制策略所需的令牌数量有所减少。

写权限的实施。 [21]中的方法假设外包数据为只读，即只有数据所有者可以更新其元组的内容，而其他方只能被授予对这些元组的读权限。这一假设与当前技术趋势（例如协作场景）不符，在这些场景中，数据所有者可能希望选择性地向其他用户授予对其资源的写权限。[17]中的方案采用选择性加密来管理写授权。其基本思想是将每个元组与一个加密的写标签（即一个独立于元组内容选择的随机值）相关联，并且仅允许知道 t写标签明文值的用户更新元组 t。对写标签的访问受到控制

通过选择性加密：元组 t的写标签使用仅由被授权写入 t的用户（即写访问控制列表中指定的用户）和服务提供商才能派生的密钥进行加密。服务提供商仅在请求用户能够证明其知晓相应的写标签时，才会接受对该元组的写请求。为此，密钥派生层次结构扩展了用于加密写标签的密钥，并引入了专门分配给服务提供商P的密钥 kP，以实现对写标签的验证。

用于加密写标签的密钥定义方式如下：（i）授权用户可以通过将已知的密钥（或通过一系列令牌可导出的密钥）应用安全哈希函数来计算这些密钥； （ii）服务提供商可通过在密钥派生层次结构中专门添加的令牌，直接从密钥 kP派生出这些密钥。需要注意的是，用于加密写标签的密钥不能用于派生层次结构中的其他密钥，因为服务提供商不可信，无法访问外包关系中元组的明文内容。例如，考虑中的加密策略，假设将对元组 t1的写权限授予用户 A， 对 t2的写权限授予 B和 D，对 t3和 t8的写权限授予 D，对t4、 t5和 t6的写权限授予 B，对 t7的写权限授予 C。展示了扩展了服务提供商密钥 kP以及加密写标签所需密钥的密钥派生层次结构。图中，新增的顶点以灰色表示，且新增的顶点和边均用虚线表示。列出了分配给用户和服务提供商的密钥，以及用于加密关系MedicalData中元组及其写标签的密钥。

ACD		AP
A		AB
A		AB
A		AB
B		AC
P		AD
C		BP
D		BD
	BD
		CP
		DP

BDP

用户密钥
A B C D	kA kB kC kD
P	kP

元组读取密钥	写入密钥
t1 t2 t3 t4 t5 t6 t7 t8	kAC kBD kAD kB kAB kB kACD kD

(b) (a)

授权策略的更新。 由于必须始终保证授权策略与加密策略之间的等价性，以确保正确执行授权，因此访问控制策略的任何更改都应通过更新加密策略来实施。事实上，所使用的密钥用于

加密每个元组 t及其写标签分别取决于能够读取和写入它的用户集合。为了实施对读权限的更新，有必要使用一个不同的密钥对策略更新中涉及的元组进行重新加密，该密钥只有其新的访问控制列表中的用户知道或可以推导。通过引入[21]以下超加密方法，将读权限授予和撤销的部分管理委托给服务提供商，从而大大降低了数据所有者执行重加密操作的开销。基础加密层（BEL）和表层加密层（SEL），每一层都有其自身的加密策略（即密钥集、密钥派生层次结构和密钥分发）。每个元组 t通过两个不同的加密层进行保护，用户只有在知晓用于在BEL和SEL对 t进行加密的两个密钥的情况下才能访问 t。在初始化时，BEL和SEL的加密策略是一致的（更准确地说，它们都等同于初始授权策略）。在发生策略更新时，BEL仅通过在公共目录中插入令牌（以允许新的密钥派生）来更新。而重加密操作则由云服务提供商在SEL上执行。

虽然在更新读取授权策略时有效，但过度加密方法无法适用于写权限的更新。事实上，用户并非毫无察觉，为写标签增加一层加密并不能防止那些已被撤销对某个元组写权限的用户利用其先前已知的该元组标签信息进行未授权的更新。实际上，为了grant用户 u 对元组 t的写访问权限，只需使用服务提供商和被授权更新内容的用户所知晓的密钥对t的写标签进行重新加密即可。相反，为了revoke用户 u 对元组 t的写访问权限，必须为 t分配一个全新的写标签，其新的明文值应独立于之前的值，并使用服务提供商以及新写访问控制列表中的用户所知晓的密钥对其进行加密。需要注意的是，由于服务提供商知道每个元组的写标签，以便正确强制执行写权限，因此数据所有者可以将她元组[17]的写标签的生成和重新加密委托给存储服务提供商。

3.2 基于属性的加密

在云场景中实施选择性访问的另一种方法是基于属性的加密（ABE[43]）。

基本技术与授权执行。 ABE 基于公钥加密方案，并根据与元组或用户关联的属性上定义的授权策略来执行访问限制。根据属性和策略如何与数据和用户关联，可将 ABE 实现为 密文策略 ABE（CP‐ABE [77]）或密钥策略 ABE（ KP‐ABE [43]）。下文简要描述这两种方法。

CP‐ABE 将每个用户 u 与一个描述性属性集以及基于这些属性生成的私钥相关联。与 u 相关联的属性描述了其在访问控制中被认为相关的特性

∧
∨ role: 医生
specialty: 心脏病学 specialty: 神经病学 执行（例如，她在公司中的角色和部门）。关系 r 中的每个元组 t 都与一个访问结构相关联，该访问结构用于建模控制对 t 访问的授权策略。图形上，访问结构是一棵树，其叶子节点表示关于属性的基本条件，其内部节点表示逻辑门（即合取和析取）。例如，假设在图2中，仅允许心脏病学或神经病学专业的医生访问关系 MedicalData 中的元组 t7。 描绘了与元组 t7 相关联的访问结构，表示布尔公式(role=‘doctor’) ∧(specialty=‘cardiology’ ∨specialty=‘neurology’)。CP‐ABE 所采用的密钥生成技术专门设计用于保证用户 u 的密钥 k 当且仅当生成 k 时所使用的属性集合满足加密 t 时所考虑的访问结构所表示的访问控制策略时，才能解密元组 t。

KP‐ABE 将每个用户 u 与一个访问结构相关联，并将每个元组与描述其特性的属性集合相关联。与每个用户关联的密钥基于其访问结构生成，而用于加密每个元组的密钥则取决于该元组的属性。KP‐ABE 所采用的密钥生成技术专门设计用于确保每个用户 u 能够解密元组 t 当且仅当与 t 关联的属性满足与用户 u关联的访问结构。

通过采用基于属性的签名（ABS）技术来提供写权限的支持。[35]中的方案结合了CP‐ABE和ABS技术，分别用于执行读权限和写权限。尽管这种方法有效，但其缺点是需要可信方的存在以确保策略正确执行。另一种类似的方法在 [62]中进行了说明，该方法基于ABE和ABS的结合使用，以支持读和写权限。与[35]中的方法相比，该解决方案的优势在于还可应用于分布式场景。

授权策略的更新。 尽管CP‐ABE能够有效且高效地实施访问控制策略，但其主要缺点之一与属性撤销的管理有关。当用户失去其某个属性时，她将不应再能够访问需要该已撤销属性才能访问的元组。然而，若不引发昂贵的重新密钥生成和/或重加密操作，属性撤销很难实施。解决此问题的方案是

提出于 [72,82,85]。在[82]中，作者展示了一种能够管理属性撤销的加密方案，确保满足后向安全（即用户无法解密需要已撤销属性的元组）和前向安全（即新用户在其加入之前已外包的所有元组均可访问，只要其属性满足访问控制策略）。在[72]中，作者提出了一种基于层次化属性的解决方案，该方案依赖于 CP‐ABE的扩展版本，其中与用户关联的属性被组织在一个递归集合结构中。为了在KP‐ABE环境中加强更新操作，[85]中的解决方案提出将ABE与代理重加密相结合，从而将执行属性撤销所必需的大部分重加密操作委托给存储服务提供商。为了减少采用非对称加密不可避免带来的开销，该方法还建议使用 KP‐ABE来保护用于加密元组内容的对称密钥。通过这种方式，只有授权用户才能获取实际用于保护元组内容的密钥。

4 细粒度访问数据

加密是保护云中数据机密性的有效手段。然而，由于云服务提供商不知道加密密钥，因此无法访问数据内容，也就无法直接对其存储的数据执行用户的查询。要求客户端下载整个加密数据集并在本地执行查询也是不可行的，因为这将抵消将数据存储委托给云服务提供商所带来的优势。当前解决方案基于索引的定义，这些索引使得服务提供商能够在无需解密数据的情况下在服务端执行（部分）查询[64],，或基于特定的加密方案，支持直接在加密数据上执行操作（![图8](图8. 一些加密函数的
| 加密 | 操作 | 任何内容 | 安全 | 无泄露 | Cost |
| — | — | — | — | — | — |
| 随机加密 | 确定性加密
OPE
Paillier | El Gamal | 全同态加密一切 | =
≥
+ | × | 泄露 重复 实用的 | 泄露顺序实用的 | 无泄露 | 无泄露 | 无泄露 | 实用的
昂贵的 | 昂贵的 |
| 不实用的 | | | | | |

4.1 用于查询执行的索引

索引是元数据，其值取决于所定义的原始关系中属性的明文值。索引是

在加密关系中作为附加属性表示。给定一个定义在模式 r(a1, . . . , an)上的关系 r，其对应的加密和索引关系 rk定义在模式 Rk(tid, enc, Ii1, . . . , Iij)上，其中Iil, l= 1, . . . , j是定义在 R中属性 ail上的索引。注意，并非 R中的所有属性都需要在 Rk中有对应的索引，仅那些预期会参与查询的属性才需要。例如， 及其对应的加密和被索引关系 (b))表示了 一个关系（a）及其对应的加密版本（b）的示例)中关系 MedicalData的加密版本，为方便读者起见，该关系也显示在 及其对应的加密和被索引关系 (b))中，其中属性ZIP、Job和Disease分别关联了索引 IZ、 I J和 ID。索引值用希腊字母表示。

引入索引使得云服务提供商能够（部分）评估客户端提交的查询 q。在存在索引的情况下，查询评估过程如下进行。

– 步骤1. 用户制定一个查询 q，该查询被发送到客户端。请注意，由于加密对最终用户必须是透明的（用户可能 unaware 关系是以加密形式存储在云服务提供商处的），q是在明文关系上制定的。– 步骤2. 在接收到 q后，客户端生成两个查询： qp，在服务提供商处使用索引对加密关系进行操作；以及 qc，在客户端对 qp的结果进行操作。然后将查询 qp发送给云服务提供商。– 步骤3. 在接收到 qp后，云服务提供商在加密关系上执行该查询，并将结果发送回客户端。– 步骤4. 客户端对从服务提供商获得的结果进行解密，并在得到的关系上评估 qc，以可能移除虚假元组（即满足索引条件但不满足用户指定的原始条件的元组），然后将查询结果返回给用户。

说明了查询评估过程。显然，将查询 q转换为查询 qp 和 qc取决于查询中涉及的索引类型。接下来，我们将根据所支持的条件对一些最著名的索引技术进行说明。

等值条件（例如，[15,46]）

等值条件是指形如 a= v的条件，其中 a为一个属性， v是属性 a域中的一个值，并由三类索引支持：基于加密的[15],基于桶的[46],和基于哈希的[15]索引。

元组的基于加密的索引 t在属性 a上的计算方式为Ek(t[a])，其中 Ek是一个对称加密函数，而 k是加密密钥。形如 a=v的等值条件随后被转换为 I=Ek(v)。例如，假设 及其对应的加密和被索引关系 (b)) 中的索引 IZ ZIP 是属性ZIP=‘94110’ 在关系 MedicalData上的基于加密的索引，则该等值条件被转换为在被索引关系 MedicalDatak上操作的 IZ=‘α’。

在属性 a上定义基于桶的索引需要将 a的域划分为不重叠的连续值子集，并为每个分区关联一个标签。对于外包关系 r中的元组 t，与属性 a相关联的索引值即为包含值 t[a]的分区的标签。因此，形式为 a=v的等值条件被转换为 I=l，其中 l是包含 v的分区的标签。例如，假设 及其对应的加密和被索引关系 (b))中的索引 I J是一个基于桶的索引，其中 ζ、 η和 θ分别是分区{农民,经理}、{护士,秘书}以及{外科医生,教师}的标签。则在关系 MedicalData上关于职业Job = ‘farmer’的等值条件被转换为在被索引关系 MedicalDatak上执行 I J=‘ζ’。

基于属性 a的哈希索引定义依赖于采用一种会产生冲突的确定性哈希函数 h。对于 r中的元组 t，与属性 a相关联的索引值计算为 h(t[a])。因此，形如 a=v的等值条件被转换为 I=h(v)。例如，假设 及其对应的加密和被索引关系 (b))中的索引 ID是一个使用函数 h计算的基于哈希的索引，使得 h(哮喘)=κ且 h(胃炎)=h(胸痛)=λ。则关系 MedicalData上的等值条件Disease = ‘胃炎’被转换为在被索引关系 MedicalDatak上执行 ID=‘λ’。

与基于加密的索引不同，基于桶的索引和基于哈希的索引都会将不同的明文值映射到相同的索引值。因此，服务提供商在等值条件评估中计算出的结果可能包含虚假元组，客户端必须将其过滤掉才能获得最终的查询结果。

范围条件（例如，[1,15,75]）

范围条件是形式为a in[v1, v2]的条件，其中 a为一个属性，[v1, v2]是 a域中的一个范围。基于桶的索引可以支持范围查询，前提是标签的定义能够保持属性值之间的顺序。然而，该方案会向服务提供商泄露属性值的顺序。另一种专门设计用于支持等值和范围条件的解决方案是基于在索引属性[15]上构建 B+‐树索引。该 B+‐树索引是在属性的明文值上构建的，并在服务提供商处表示为具有两个属性的加密关系：id，包含节点标识符，以及content，包含加密的节点内容。指向子节点的指针通过节点标识符表示。

)展示了在关系 MedicalData的姓名属性上构建的 B+‐树的一个示例，该关系如 一个关系（a）及其对应的加密版本（b）的示例)所示。为了检索满足范围条件的元组，客户端迭代地查询表示 B+-的服务提供商处的树。客户端随后将执行一系列查询，从根节点开始，在每一层检索到感兴趣叶节点路径上的节点。例如，参考)中的示例，要检索姓名在 E和 G之间的患者，客户端按顺序访问加密关系中的元组1、3、9和10。

一种支持范围条件的替代技术依赖于Order Pre-serving Encryption Schemas（OPES [1]）或Order Preserving Encryption with Spliting and Scaling 方案（OPESS [75]）。OPES 是一种加密技术，其输入为索引值的目标分布，并应用保持顺序的变换，以确保索引值遵循目标分布。OPESS 则保证生成的索引值遵循平坦的频率分布，这是通过将相同的明文值映射到多个索引值得以实现的。由于索引值保持了顺序，服务提供商可直接在索引上评估范围条件。

聚合操作符（例如，[38,45]）

为了计算聚合函数（如sum和 avg），必须使用支持算术运算的索引，这些索引通过同态加密[61], ——一种允许对加密数据执行基本算术运算（即+、 −、×）的特定加密方案——来构建。因此，服务提供商可利用这些索引来评估聚合函数以及等值和范围条件[45]。一种完全同态加密方案（其中完全意味着同态性质对于在加密数据上执行的任何操作均保持有效）已在[7,38]中提出并研究。该方案允许在无需解密的情况下对加密数据进行任意函数计算。然而，这种技术存在较高的计算复杂度，因而不适用于实际应用场景。在[12,13]中，作者提出了一种可实施且公钥更小的完全同态加密方案，因此比传统方案更易于管理和高效。

4.2 CryptDB

CryptDB[60]支持在云服务提供商处直接对加密数据执行查询，而无需依赖与外包关系相关联的索引。为此，CryptDB 针对每个属性采用不同类型的加密方式（即随机加密、确定性加密、保序加密、同态加密、连接、保序连接和关键字搜索[60]），并根据需要执行的查询动态调整这些加密方式。外包关系中的每个单元格都被包裹在多层加密层中，形成一种洋葱结构，使得同一属性值经过多次加密后得到存储在服务提供商处的值。注意，同一列中所有单元格的加密层是相同的，但不同属性之间的加密层可能不同（取决于所需支持的查询类型）。展示了一个明文数据项被洋葱式加密结构包裹的示例。最外层采用最强的加密方式（即随机加密加密，一种概率性方案，其中两个相等的值可能以不可忽略的概率被映射到不同的密文[60]），而最内层表示明文数据。从最内层向外，所采用的加密方案提供的安全保证较弱，但支持对加密数据进行更多的计算。

CryptDB 提出动态调节加密的使用，可能根据待执行查询中的操作移除部分加密层。加密层的调整是动态的，即取决于正在执行的具体查询。例如，如果服务提供商需要在属性 a 上执行 group by 操作，则应能够确定 a 的哪些值彼此相等，但不能获知 a 的明文值。由于随机加密不支持此类功能，因此将其移除，仅保留使用确定性方案加密的数据。由于后一种方案支持分组操作，因此无需进一步剥离。需要注意的是，一旦某个属性的加密层被移除，由于数据已暴露给服务提供商，该加密层便无法恢复。

使用CryptDB的查询执行假设存在一个可信代理，该代理拦截用户与云服务提供商之间的所有通信。该代理存储一个秘密主密钥 k、数据库模式以及关系中每个属性的当前加密层。查询评估过程的操作如下。

– 步骤1. 用户制定一个查询 q，该查询被发送到代理，代理将其重写为在涉及的属性加密版本上操作的等效查询qˆ 。然后，代理使用其自身的密钥 k对 q中的所有常量值进行加密，采用最适合要执行操作的加密方案。– 步骤2. 代理检查是否应允许服务提供商在执行查询qˆ之前移除某些加密层，如果是，则发出一个update查询，以移除相关属性的特定加密层。代理将qˆ转发给云服务提供商，由其执行。– 步骤3. 服务提供商将qˆ的加密结果返回给代理。– 步骤4. 代理对收到的qˆ的结果进行解密，并将其发送给用户。

展示了CryptDB中的查询评估过程。

5 保护查询机密性

当用户向云服务提供商提交查询时，由于查询本身的信息，她的隐私（以及所访问数据的隐私）可能面临风险[25,31,79]。例如，知道某个用户向外包医疗数据库提交了关于肝癌症状的查询，可能隐含地揭示出她本人或其亲近的人患有此类疾病。此外，还可能通过分析用户执行的数据访问来推断外包数据集的 （私有）内容。例如，如果观察者了解所考虑数据域中值的访问频率，她就可以通过监控频繁访问的元组模式来推断这些元组的值。为了应对这些隐私风险，必须妥善保护查询机密性。保护查询机密性需要确保数据访问和模式 机密性，分别指保护访问目标以及两次访问指向同一目标这一事实。

传统上，访问机密性和模式机密性通过私有信息检索（PIR）技术来解决。然而，这些方法无法保护所访问数据的机密性，并且具有较高的计算成本（例如，[8,56]）。尽管已提出多种方案用于保护数据和访问机密性（例如， [39,59,69,73]），但它们在保护模式机密性方面仍存在不足。在本节接下来的内容中，我们将介绍一些能够同时保护数据、访问和模式机密性的最新技术。这些解决方案的基本思想是通过采用动态分配的数据结构[52,83]，打破磁盘块与其存储信息之间原本静态的关联。

不经意RAM（ORAM）。 Oblivious RAM(ORAM)[40]数据结构是多种旨在保护加密数据集访问和模式机密性的方法的基础。在ORAM中，加密数据被组织成一组 n加密块，存储在一个金字塔形数据结构中。ORAM结构的每一层 l存储 4l块，并关联一个布隆过滤器和一个哈希表，以确定某个给定块是否存储在该层 l，如果是，则通过哈希表识别该块所在的存储位置[79]。在搜索过程中，从金字塔顶部开始逐层访问ORAM结构。在每一层，提取一个元素（目标元素）

访问或随机元素（如果目标不属于已访问的层级），并将其放入缓存中。注意，即使找到目标块，访问也不会终止，以避免向云服务提供商泄露任何信息。当缓存满时，它将与ORAM的第一层合并，所有元素随后被重新洗牌（即在服务提供商的磁盘上分配到不同的物理块），以破坏旧数据项与新数据项之间的任何对应关系。类似地，当第一层（通常为第i层）满时，它将与第二层（通常为第i+1层）合并，并对其元素进行洗牌。

虽然ORAM能有效保证访问和模式机密性，但对金字塔结构较低层级的重组织成本非常高昂。因此，在数据库较低层级重排期间提交的访问请求可能会面临较高的响应时间。为了降低此类成本，[34]中提出的方案将洗牌操作限制在存储被访问元组的块上。大多数ORAM解决方案依赖于服务提供商端运行的安全协处理器。然而，这一假设在许多现实场景中可能并不可行。为减少访问时间的替代方案基于最小化客户端与服务提供商之间交互次数的思想， [41,78],或支持并发访问[42,80]。

路径ORAM是传统ORAM结构的最新改进，它减少了由于ORAM结构中较低层重新组织所带来的开销[70,71]。路径ORAM提出将数据组织成树形结构，其中节点为桶，每个桶存储固定数量的块，块中可包含虚拟元组或真实元组。每个块被映射到一个随机叶节点，并存储在客户端（位于称为暂存区的本地缓存中），或存储在其关联叶节点路径上的某个桶中。读操作会从服务提供商下载并暂存从根节点到目标元组所映射叶节点路径上的所有桶。随后，目标元组的映射会被随机更改，即在树中选择一个新的叶节点。接着将访问过的路径写回，可能同时将暂存区中的一些元组插入到写回的块中。只有当块位于该元组所映射叶节点的路径上且未满时，才能将元组插入该块。在插入元组时，路径 ORAM优先选择靠近该元组所映射叶节点的块。

洗牌索引。 一种最近提出的用于保护访问机密性和模式机密性的高效技术，基于定义一种洗牌索引[25]。洗牌索引是一种用于组织存储中数据并高效执行用户查询的隐私保护索引技术。它可以在三个抽象层次上进行理解：抽象层、逻辑层和物理层。在抽象层，洗牌索引是一棵无链的 B+‐树，其分支因子为F，构建在被索引关系的候选键K之上。树中的每个内部节点有 q ≥ F/2个子节点（根节点除外，其子节点数 1 ≤ q ≤F），并存储 q−1个有序键值 val1 ≤… ≤ val q −1。一个节点的第i个子节点表示存储介于 vali与 vali+1之间 所有值的子树的根节点。叶子节点存储实际的元组及其键值。与传统的 B+‐树 结构不同，叶子节点是

未以链式连接（以隐藏相对值顺序）。展示了一个扇出3的非链式 B+‐树示例。

在逻辑层，每个抽象节点 n由一对 〈id, n〉表示，其中id是与该节点关联的逻辑标识符，而 n是其内容。抽象数据结构中内部节点的子节点指针通过节点标识符来表示。展示了中抽象索引的逻辑表示示例。注意，逻辑标识符的顺序不一定反映节点内容之间的值序关系。为了便于阅读，图中每个节点顶部标出了逻辑标识符，且其第一位数字对应于该节点在树中的层级。

最后，在物理层，每个逻辑节点 〈id, n〉都与一个随机盐值连接，以破坏明文可区分性，然后使用对称加密算法以CBC模式进行加密。节点的逻辑标识符可直接转换为物理地址，用于指示该加密节点所对应的块在服务提供商处的存储位置。展示了中逻辑索引的物理表示示例，这对应于云服务提供商的视图。

通过结合采用以下三种保护技术，可提供对访问和模式机密性的保护。

– 覆盖搜索。 覆盖搜索是虚假的搜索，服务提供商无法识别其为虚假，在实际搜索目标值的同时执行。对于洗牌索引的每一层（根层级除外），客户端下载 num cover+1个块：一个用于通往目标节点的路径上的节点，以及 num cover个用于通往覆盖节点路径上的节点。因此，从服务提供商的角度来看，每个被访问的叶块存储目标值的概率均相同。覆盖搜索必须保证两方面的特性：不可区分性（即服务提供商无法判断被访问的块是覆盖块还是目标块）和块多样性（即通往覆盖块和目标块的路径必须互不重叠，根节点除外）。

– 缓存搜索。 缓存搜索使得对节点内容的重复访问与非重复访问无法区分。缓存是一种分层结构，每一层对应洗牌索引中的一个层级。它在客户端以明文形式维护，并存储通往洗牌索引中最近num次访问目标路径上的节点。缓存的每一层均按照最近最少使用（LRU）策略进行管理：这样，每个被缓存节点的父节点（从而连接该节点到树根节点的路径）也都会保留在缓存中。每当访问的目标位于缓存中时，在访问过程中会使用额外的覆盖，以确保在树的每一层级 （除根层级外）都下载 num cover+1个块。本地缓存的使用可防止短期交集攻击，此类攻击可能被服务提供商利用，通过后续搜索下载非不相交的块集合来识别重复访问。

– 洗牌。 洗牌会打破块与其存储的节点内容之间的关系。通过这种方式，对同一物理块的访问可能不再对应于对相同节点内容的访问。洗牌包括将被访问（无论是作为目标还是作为覆盖）以及被缓存的节点内容移动到不同的块中。然后，洗牌会从已下载的块中选择，为每个被访问的节点分配一个不同的块。为了防止服务提供商推断出有关洗牌的信息，每次节点被移动到不同的块时，都会使用不同的随机盐值对其进行重新加密。被洗牌节点的父节点会被更新，以保持结构的一致性。

搜索过程在客户端进行，从根节点到叶子节点逐层访问洗牌索引的 B+‐树。每次访问都结合了上述三种保护技术，且该搜索过程可保证访问机密性和模式机密性[25]。以中对洗牌索引的访问为例，假设要搜索 z3，采用的覆盖为 x1，且缓存中包含到值 y2的路径。由于客户端缓存中有根节点 r，它首先从服务提供商处下载第1层中沿到 x1（存储值 x的块103）和到z3（存储值 z的块102）路径上的块。然后解密并洗牌已访问及缓存中的第1层节点，例如将 x分配给块102，将 y分配给101，将z分配给103。由于洗牌操作，客户端更新根节点，加密其内容并将其写回服务提供商。随后在第1层缓存中插入节点 z。接着客户端下载并解密沿到 z3和 x1路径上的第2层块（分别为202和207）。解密这些块以获取搜索目标，并将其内容与缓存中的节点 y2（205）一起进行洗牌。客户端根据洗牌结果更新节点 x、 y和 z的内容，重新加密后写回服务提供商。类似地，它也将块202、205和207加密后写回服务提供商。同时，将节点 z3插入缓存。展示了云服务提供商视角下读取和/或写入的块访问情况。显然，服务提供商既无法判断被访问的叶子节点中哪一个才是访问目标，也无法得知块内容是如何被洗牌的[25]。

原始的洗牌索引方案已扩展，以支持对数据的并发访问、对非密钥属性的访问（例如，[27]），以及在分布式系统中运行（例如，[26,28]）。

6 保护查询完整性

在云中存储和处理数据时，另一个需要考虑的重要问题是用户验证云服务提供商行为正确性的能力。这意味着需要向用户提供技术手段，使其能够检查查询结果的正确性、完整性和新鲜度。正确性意味着结果是基于原始数据执行的，并且计算过程正确无误。完整性意味着查询结果中没有缺失任何元组。新鲜度意味着查询结果是基于数据的最新版本计算得出的。目前提出了两类技术来提供此类保障：确定性加密技术（第6.1节）和概率性技术（第6.2节）。

6.1 确定性加密方法

确定性加密方法通常基于采用认证数据结构，例如签名链、Merkle哈希树和跳表（例如，[32,51,54,57,58,84]）。这些方案在外包数据集上构建一个认证数据结构，并针对每个查询 q返回一个从该结构中提取的验证对象VO，用于结果验证。如果 VO与数据结构一致，则可保证查询结果正确且完整。由于这些结构定义在整个数据集合之上，认证数据结构还能提供存储数据的完整性，因为当检查查询结果的完整性时，任何未经授权的修改都能立即被检测到。

签名链。 签名链最初被提出用于验证在外包关系 r上执行的范围查询[57]结果的完整性，该外包关系在域 D上定义，并基于属性 a的全序关系进行组织。这些技术采用单向哈希函数 h，并要求根据属性 a的值对 r中的元组进行排序。每个元组 ti关联的签名通过签名以下字符串计算得出：将 h(ti−1)与 h(ti)连接后的结果，其中 ti−1是排序中位于 ti之前的元组。对于在 a上执行的范围查询 q，客户端可通过检查查询结果中元组的签名立即发现结果的不完整。例如，假设在计算查询结果时遗漏了元组 ti。当检查元组签名时，客户端会发现所计算的 ti+1的签名（即 h(ti−1)||h(ti+1)）与存储在 ti+1上的签名 h(ti)||h(ti+1)不同。由于签名链仅针对其定义的属性保证查询结果的完整性，因此应为可能参与查询的每个属性定义一个签名链

范围查询。该方法的主要局限性在于与每个元组关联的签名大小，其随着签名链数量的增加而线性增长。

Merkle哈希树。 通过在外包关系[54]上构建Merkle哈希树，也可以提供查询计算的完整性。给定一个关系 r，Merkle哈希树是一种二叉树，其每个叶节点存储对 r中一个元组应用单向哈希函数 h的结果，每个内部节点存储其子节点值连接后的哈希值。树中叶节点内的元组按照属性 a的值进行排序。Merkle哈希树的根节点由数据所有者签名，并发送给授权用户。展示了在 一个关系（a）及其对应的加密版本（b）的示例)中关系 MedicalData的属性名称Name上定义的一个Merkle哈希树示例。对于在一个属性 a上执行的范围查询，返回给请求客户端的结果还包括一个验证对象 VO，其中包含客户端计算根节点值所需的所有节点值。为了验证查询结果的正确性和完整性，客户端利用 VO和查询结果中的元组重新计算根节点的值，然后检查所计算出的值是否与最初从数据所有者处获得的根节点值一致[32]。VO的计算取决于待执行查询的类型。例如，在返回特定元组的选择查询情况下， VO包含从根节点到对应返回元组的叶节点路径上各节点的所有兄弟节点的值。参考中的关系 MedicalData以及中的Merkle哈希树，考虑一个返回姓名为弗雷德Fred的患者的查询。该查询返回元组t6，其 VO包含图中的灰色节点。

h1 =h(t1) h2 =h(t2) h3 =h(t3) h4 =h(t4) h5 =h(t5) h6 =h(t6) h7 =h(t7) h8 =h(t8)
h12=h(h1||h2) h34 =h(h3||h4) h56 =h(h5||h6) h78 =h(h7||h8)
h1234=h(h12||h34 h ) 5678=h(h56||h78)
根节点=h(h1234||h5678)

。[32]中所示的原始技术已得到扩展，以提高验证过程的效率（例如， [51,58]），并支持对连接结果进行完整性验证[84]。

跳表 另一种可用于验证在元素集合中搜索键值的查询完整性的认证结构是

)

由 跳表 [33]实现。一个用于包含不同键值的集合的 S跳表是一组列表S0， S1，…，Sk，满足以下条件：（i） S0以非递减顺序包含 S中的所有密钥，以及哨兵 −∞和+∞；并且（ii）列表 Si， i= 1，…， k包含中所含密钥的任意子集，但始终包括哨兵 Si−1和 −∞。)展示了一个具有三层的 S={5,6,8,9,10}的跳表。在跳表中对键值的搜索操作 v从顶层列表中的哨兵 −∞开始（即， Sk），并通过向前跳跃操作，在当前列表中向右移动，直到访问的键值 vi是小于或等于 v的最大值，以及向下移动，即向下一层列表移动（从 S j 到 S j −1）。搜索操作反复进行向前跳跃和向下移动，直到到达底层列表 S0。例如，参考)中 所示的跳表，其中对值9的搜索过程被展示，被访问的节点以灰色表示。

跳表可以高效地用于验证在 S中搜索值 v的查询的完整性。为此，通过对 S定义的 跳表进行认证来实现

可交换且抗碰撞的哈希函数（即满足h(x, y)=h(y, x)的哈希函数）。跳表中的每个节点都关联一个标签，该标签通过可交换且抗碰撞的哈希函数计算得出，其值依赖于该节点右侧和下方的元素。对于底层列表 S0中的节点，节点 v的标签 f(v, S0)计算方式如下：若其右侧的节点 w也属于 S1（即 f(v, S0) = h(v, w)），则标签为该节点的值 v与右侧节点值的哈希；否则，标签为该节点的值 v与右侧节点标签 f(w, S0)的哈希（即 f(v, S0) = h(v, f(w, S0)）。例如，参考)， f(9, S0) = h (9, 10)，而f(6, S0) = h(6, f(8, S0))。对于 Si中的节点v，其标签 f(v, Si)的计算方式如下：若其右侧的节点 w也属于 Si+1（即 f(v, Si) = f(v, Si−1)），则标签与 v在 Si−1处的标签相同；否则，标签为该节点下方节点的标签与右侧节点标签的哈希 （即 f(v, Si) = h(f(v, Si−1) f(w, Si)）。例如，参考)中的 S1， f(5, S1) = f(5, S0)，而 f(6, S1) = h(f(9, S1) f(6, S0))。跳表的起始节点 s（即顶层列表中的第一个哨兵节点）的标签由数据所有者签名后发送给所有授权用户。

如果查询元素 v返回一个肯定回答（即 v ∈S），则完整性验证过程检查该值本身的存在性。否则，它验证列表 S0中两个连续元素 v′和 v′′的存在性，使得v′< v< v′′。为此，客户端接收一个验证对象，其中包含构成通往 v路径的节点右侧和下方节点的标签，这些标签对客户端计算所接收节点的标签而言是必要且充分的。例如，考虑)中的跳表，并假设搜索键值9。)突出了被访问的节点（灰色节点）以及包含在验证对象中的节点（虚线节点）。随后，验证对象对应于列表 〈9, 10, f(6, S0)， f(−∞, S1)， f(10, S2)〉。客户端通过哈希运算验证对象中的值，并将结果与跳表起始节点 s的标签 f(s)进行比较，从而验证答案。

由于插入/删除值 v对 S的修改会转化为对关联跳表的更新，该更新可在 O(log(||S||))时间内高效完成，以插入/删除 v。

6.2 概率方法

第6.1节中描述的所有技术仅能评估在已构建认证结构的属性上查询结果的完整性