Searchable Encryption for Healthcare Clouds:A Survey 翻译

自己学习用，原文翻译，侵权删

（2017）

摘要：

将医疗数据及其搜索服务外包给第三方云已经成为许多医疗实践的流行趋势，因为使用医疗云服务可以帮助降低电子健康记录(EHR)系统的成本，包括前端拥有成本和IT维护负担。医疗保健云应用程序需要具有以下两种功能的可搜索加密，以保护数据隐私和访问隐私:(1)医疗保健提供商需要与授权用户共享加密数据，并支持通过加密数据进行查询;(2)他们还需要保持查询关键字和相关搜索操作的私密性，这样医疗数据托管服务提供商就不能访问未经授权的内容，或跟踪和推断存储在医疗云中的敏感数据。本文描述了医疗保健应用程序上下文中可搜索加密(SE)的概念，并将SE用例描述为医疗保健中的四个场景。然后根据不同的EHR检索场景和需求，全面概述了四种具有代表性的SE技术:可搜索对称加密(SSE)、关键字搜索公钥加密(PEKS)、关键字搜索属性加密(ABKS)和关键字搜索代理重加密(PRES)。我们从安全性、效率和功能等方面对不同的SE方案进行了分类和比较。这项调查旨在帮助在计算机科学(CS)领域有经验的研究人员，以及领域科学家或具有有限的CS和信息安全背景的医疗保健专业人员的非专业人员。因此，我们倾向于对最新的可搜索加密模型和底层关键技术的技术综述，而不是对各自SE算法的详细证明和构造。我们描述了现有的SE方案如何相互关联和不同，并指出SE技术与医疗保健应用程序的安全和隐私需求以及开放研究问题之间的联系。

索引术语:可搜索加密;医疗云;安全;效率;连接和表达关键词搜索。

1 INTRODUCTION

如今，许多医疗保健提供商已经采用了某种形式的电子病历系统。为了减少成本的电子健康记录(EHR)系统的前端所有权和维护负担,大部分医疗实践改变了外包选项和在集中式数据库存储电子健康档案数据的第三方云不完全可信,可能驻留在远程位置。然而，当EHR数据存储在第三方和可能不可信的云上时，数据保护和数据访问方面的安全和隐私就成为关键问题。

1.1 Healthcare Cloud Needs Searchable Encryption

医疗保健云的安全性和隐私问题主要来自云计算的固有属性，比如动态资源和服务的组合和整合、多租户、异构性和开放性等。在典型的云环境中，资源、服务和用户是高度动态的，计算和通信配置是工作负载需求驱动的，经常变化，因此，云解决方案给EHR系统带来了新的安全和隐私问题。首先,当医疗实践外包云存储服务来存储他们的电子健康档案数据在一个偏远的云,这些医疗实践需要面对的风险他们的电子健康档案数据被暴露在云服务提供商通过未经授权的访问侵入存储医疗数据的隐私和机密性。其次，来自不同医疗实践的医疗数据通常托管在同一个存储云中进行数据访问和处理。这种多租户云平台有利于云计算资源共享，但很容易被对手误用和滥用：一个恶意的云租户可能会对其他租户发起各种类型的攻击，如通过资源密集型的方式导致拒绝服务(DoS)攻击问题，使其他租户的服务不可用，或者通过侧通道侵犯同一主机上其他租户的数据和数据访问的隐私信息。第三，由于云服务平台的开放性，无法验证的第三方应用程序可以使对手更容易窃取或破坏存储在医疗保健云中的机密EHR数据。

医疗保健云是一种关键任务云服务，它要求医疗实践在数据和数据访问方面提供更强的安全性和隐私保障。首先，为了防止存储数据的信息泄露，所有存储在医疗云上的医疗数据都应该进行加密。加密虽然保证了医疗数据的保密性，但也给使用带来了不便。例如，传统的数据分析和处理方法不能再用于加密的数据。一般情况下，基于明文的信息检索方法不能直接用于加密数据。此外，云所宣扬的数据共享已经变得极其困难。在一个极端，启用搜索功能的一个琐碎但不切实际的解决方案是让用户下载他们在外包时加密的整个数据库，在本地解密，然后在本地的明文数据中搜索所需的数据。这种方法同时存在效率和隐私泄露的风险:一方面，当只需要访问一小部分数据库时，下载整个数据库的成本很高，效率也很低。另一方面，对于那些被授权只访问数据库的一部分的用户来说，这是不切实际的，因为这种方法将向用户展示整个数据库，违反了HIPAA提倡和规范的隐私政策的需要。另一方面，用户可以让服务器解密数据，在服务器端通过数据库运行搜索查询，然后只将结果发送回用户。然而，这种方法允许服务器从明文数据中学习，并击败基于加密的保护存储的EHR数据，以防止云提供商的未经授权的读写。因此，医疗保健云需要强大的保护机制，既要保证EHR数据的保密性，又要允许用户轻松操纵数据。例如，用户可以动态选择自己的用户组，允许他们以不同的授权权限强度共享自己的EHR数据;授权用户可以有效地获取他们需要的信息。此外，为了确保云是否忠实地执行了用户请求的操作，云对存储和加密数据的所有操作都应该是可验证的。

1.2 Searchable Encryption: Definition and Metrics

可搜索加密是一种加密原语，它以支持对加密数据进行关键字搜索的方式对数据进行加密。可搜索加密服务包含三种类型的实体:数据所有者、数据用户(数据用户s)和不受信任的云。数据所有者是将原始数据外包给第三方云的云服务用户，从云服务提供商租用存储服务，同时提供存储空间和基于SE的访问服务。图1为可搜索加密服务的系统模型。考虑到外包数据的隐私性，数据所有者在上传数据到云之前对数据进行加密。数据用户是云服务消费者，比如Alice，她已经授权搜索和读取加密格式的外包数据。她使用生成的搜索令牌向云发出一个关键字查询。云的SE服务使用搜索令牌对加密数据进行搜索，并将匹配结果返回给数据用户。

 一个可搜索的加密方案通常包含四种算法:设置、加密、令牌生成和查询。由可信第三方运行的设置算法，用于为方案生成密钥(或公钥设置中的公钥和私钥对)。数据所有者运行加密算法生成加密数据。令牌生成算法由数据用户运行，以在其查询关键字上创建搜索令牌。云运行的查询算法使用搜索令牌对加密的数据进行搜索，并将匹配的数据返回给数据用户。

可搜索加密最早是由Song等人引入并正式定义的[1]，其定义和安全强度措施随着时间的推移沿着两个主要研究维度演变:可搜索对称加密(SSE)和可搜索非对称加密(SAE)。SSE只允许密钥持有者创建可搜索的密文和搜索令牌。虽然SAE允许任何人使用解密者的公钥加密数据，但只有私钥持有者才能执行搜索。根据不同场景的需求，SAE主要发展为三种类型:关键字搜索公钥加密(PEKS)、关键字搜索属性加密(ABKS)和关键字搜索代理重加密(PRES)。

效率、安全性、查询表达性和功能是SE研究的每一行中讨论的四个主要问题。效率由方案的计算和通信复杂度来衡量。SE方案的安全性随着时间的推移而发展。因为安全性从来都不是免费的，所以在一端的安全性和另一端的效率和查询表达性之间总是要权衡的。通常，安全性较高的SE方案可能具有较高的复杂性。SE方案的查询表现力定义了支持哪些类型的搜索查询，例如搜索关键字的数量、谓词的类型。例如，关键词的数量可以分为单关键字搜索和多关键字搜索。同样，查询谓词也可以分为精确匹配查询、范围查询、子集查询、合取查询等。在现有的SE方案中，通常情况是查询的表达性越强，查询评估的效率就越低，安全性也就越弱。SE方案的功能还包括该方案支持的其他使用或安全功能，例如动态更新、可验证性、用户撤销等等。在目前的大多数方法中，SE方案支持的功能越多，其构造的复杂性就越高，效率也就越低。因此，SE方案的设计中有四种类型的权衡:(1)效率与安全性，(2)安全性与查询表现力，(3)效率与查询表现力，以及(4)效率与功能。

1.3 Searchable Encryption in Healthcare Applications

不同的医疗保健应用场景需要不同的可搜索加密方案。我们将现有的医疗保健应用程序场景描述为四种类型:(1)当外包数据仅由数据所有者搜索，且数据所有者是搜索加密数据的唯一授权数据用户时，SSE方案可以应用于这个自用场景。(2)当外包数据与另一个用户共享时，即只有一个授权数据用户可以创建搜索令牌并搜索加密数据时，PEKS方案适合于这种一对一的场景。(3)当外包数据被多个用户共享时，即多个授权用户具有搜索加密数据的权限时，ABKS方案可以用于这种一对多的场景。(4)当数据所有者不可用且在紧急情况下无法直接授予搜索授权时，需要授权的委托用户代表该数据所有者将搜索权限重新授权给其他用户。PRES方案适用于这种授权委派场景。

在随后的章节中，我们将首先描述可搜索加密的概念，并详细阐述医疗保健场景的四种类别中的每一种。然后，我们将根据外包医疗保健云中的不同医疗数据检索场景，对每种类型的SE方案进行详细讨论，并强调其中的开放挑战。

1.4 Scope and Contributions

本调查报告全面概述了可搜索加密技术，并通过医疗保健应用案例激发了它们的实际用途。除了在医疗保健应用程序的上下文中引入可搜索加密(SE)的概念外，本文还将SE用例描述为医疗保健上下文中的四个场景。然后我们对四种具有代表性的加密技术进行了全面的概述:可搜索对称加密(SSE)、公钥加密与关键字搜索(PEKS)、基于属性的加密与关键字搜索(ABKS)和代理重加密与关键字搜索(PRES)。我们从安全性、效率和功能方面对不同的SE方案进行分类和比较。通过关注两种SE方案的基本安全定义和安全构造，该文提供了可证明安全的可搜索加密(SE)的调查:(i)可搜索对称加密(SSE)和(ii)公钥加密与关键字搜索(PEKS)，我们的论文不仅提供了四种类型的可搜索加密方案的更广泛的类别，而且提供了一个易于理解的说明，说明如何在医疗保健领域利用这四种类型的SE方案来提供医疗保健数据和患者的隐私和安全。

这篇调查论文旨在为非专业人员提供一个简单的切入点，也有利于有经验的研究人员跟上可搜索加密的最新方法。我们指出SE和医疗保健应用程序场景之间的连接，确定每个场景的SE解决方案，并指出开放的挑战。我们推测，这项调查也有助于从业人员找到适合许多不同的医疗保健应用场景的SE方案。

本文的其余部分组织如下。第二节电子病历数据索引的背景资料及本调查中使用的隐私概念。在第3节中可以找到四种EHR数据检索场景的讨论。根据这四种医疗保健应用场景，SE方案的四种类型:SSE、PEKS、ABKS和PRES依次在第4节、第5节、第6节和第7节中详细介绍。第8节提供了SE的实现建议。第9节讨论了无关RAM (ORAM)、同态加密(HE)和差分隐私的相关工作。第10节总结并讨论了未来的工作。

2 EHR DATA AND PRIVACY REQUIREMENTS

在本节中，我们将介绍电子病历数据的背景信息、索引结构以及本次调查涉及的隐私问题。

2.1 Inverted Index-Based Structure of EHR Data

基于索引的倒排结构是一种索引数据结构，用于存储从内容(例如关键字)到一组文档的映射，它更适合于搜索EHR数据，原因有以下三个。(1)理论上，一个文档可以被看作是由若干关键字组成的。我们可以直接使用可搜索的加密方案加密文档，并在加密的文档上执行关键字搜索。但是这种方法的搜索效率会非常低，因为搜索复杂度在所有文档的大小上都是时间线性的。虽然倒排索引允许快速的关键字搜索，但它是文档检索系统和大型搜索引擎[3]中最常用的数据结构。(2) EHR数据不仅包括文本，还包括各种图像格式，如x射线和超声波，通常使用与医学成像对象相关的注释文本进行搜索，而不是直接搜索原始图像。在搜索这类医学图像时，在每张图像的注释关键字上建立一个倒排索引。(3)一般来说，病人为了某一特定疾病的诊断而去找一位专门的医生。因此，EHR数据总是根据医生的不同角色进行聚类。以医生的角色为关键词，建立索引比较容易。

如图2所示，本例患者EHR数据的结构为一个三层树状结构。树的根是患者节点，比如Level 1。Level 2是医生的角色节点。为了得到专业的治疗，病人可能会在不同的医院看多个医生。例如，第一医院的整形外科医生建议，如果患者的腿骨折，就进行手术。因为二院是一家非常有名的骨科医院，病人去二院做手术。因此，患者关于外科医生的EHR数据来自两个不同的护理提供组织(CDOs)。

在图2中，我们使用h1表示医院1,h2表示医院2。角色节点的子节点是医学诊断节点和其他实验室检验测试节点。只有这些叶节点包含EHR数据，如处方、诊断等。因此，树有两种类型的节点:包含真实EHR数据的叶节点和实际为EHR数据索引的上层内部节点。前一个节点称为数据节点，用矩形表示，后一个节点称为索引节点，用椭圆表示。显然，在这种结构中，所有的数据节点都是按照角色节点嵌套的，这样就可以方便地由不同角色的医生检索。

在前面的EHR数据结构中，第2级的索引节点可以作为搜索的关键字。当云根据查询的关键字找到匹配的索引节点时，将数据节点返回给数据用户。然而，在这种倒置的基于索引的结构中，当EHR数据存储在远程医疗云中时，不仅需要加密它们，而且索引也需要加密，因为很容易从索引节点中推断出关于患者的敏感信息。本文采用可搜索加密方案对索引进行加密，并支持对加密数据进行搜索操作。用于加密EHR数据的加密方案可以是任何安全的可搜索的加密方案。数据所有者可以根据不同的医疗应用场景及其各自的隐私需求选择不同的加密方案。

在本文的其余部分，我们设D={d1, d2，…， dm}表示要存储在第三方且可能不可信的医疗保健云中的EHR数据集，其中|D| = m是EHR数据的总数。根据上述EHR数据结构，每个EHR数据di都由一个或多个关键字进行索引。让I= {w1 w2, . .，w2}是D中的索引，其中|I| =n是关键字的总数。表示用关键字wi索引的EHR数据集。关键词和EHR数据集分别通过加密算法Enc和E加密，并存储在医疗保健云中。再次注意，Enc和E是不同的加密方案:Enc是一种可搜索的加密方案，E可以是数据所有者选择的任何安全加密方案。

2.2 Privacy Requirements in SE Schemes

直观地说，如果服务器除了加密的查询结果之外，对查询和文档一无所知，则SE方案是安全的[1]、[4]、[5]、[6]。在本节中，我们将详细讨论基于索引的数据存储结构的特定隐私需求，其中云服务器将搜索一组可搜索的索引，而不是直接搜索加密的数据。

Data privacy 数据保密性是电子病历资料的一项基本要求，即外包的电子病历资料不应以任何形式透露给任何未经授权的人士，包括云服务供应商。通常，它可以通过加密算法来保证。拥有密钥的用户从云服务器中检索到编码后的EHR数据后，可以有效地对其进行解密。基于加密的保护需要考虑以下三种类型的隐私保护要求:(i)由搜索关键字引起的泄漏，(ii)由搜索模式引起的泄漏，(iii)由访问模式引起的泄漏。

Privacy of search keywords. 这与明文隐私有关:如果云服务器从索引中推断出频繁关键字与加密数据集之间的任何关联，它可能会了解到EHR数据的主要内容。因此，构建可搜索索引时，应避免云服务器进行此类关联攻击。这种类型的安全性也称为security against chosen keyword attack (CKA)。在SE方案中，加密索引的随机性保证了云服务器的安全性。

Privacy of search patterns. 数据用户通常不希望他们的查询被公开给其他人，也就是，对应的标记所指示的关键字。在文献[7],[8],[9],[10]中，这种泄漏被称为搜索模式。也就是说，搜索模式揭示了在过去是否执行了相同的搜索。访问搜索模式允许服务器使用统计分析并确定有关查询关键字的信息。使用确定性活板门直接泄露了搜索模式。现有的随机SE方案使用随机生成的令牌来保证用户搜索模式的隐私性。随机SE方案的安全概念称为谓词隐私[6]。请注意，随机令牌生成算法只有助于保护云服务器的外部对手，而不能保护内部对手(例如，云管理员)，因为在每个搜索过程中接触的索引条目也公开了搜索模式。减少这种泄漏的一种可能方法是对关键字重新排序，并周期性地重新生成索引，比如半月或每月。

Privacy of access patterns. 除了上述隐私要求之外，我们还注意到，大多数SE结构的搜索结果序列可能会揭示关键字的信息，因为云服务器总是会为相同的查询关键字返回相同的文档集。这种泄漏称为访问模式[7]。访问模式是指查询结果所隐含的信息。只有ORAM可以隐藏访问模式。但是ORAM是计算密集型的，对于真实世界的数据集伸缩性不好。在实践中，可以减少(但不能消除)访问模式的泄漏。例如，可以在位图中随机插入假文档[11]。

在本文中，我们关注于确保针对任何对手的明文隐私以及针对云服务器外部对手的断言隐私的技术。上述技术还可以与四种SE方案相结合，以减少搜索和访问模式泄漏。

3 HEALTHCARE SCENARIOS FOR SE

在本节中，我们将介绍医疗保健云应用程序的四个搜索场景。然后，我们在接下来的部分中讨论每种场景下的可搜索加密方案。

 3.1 The First Scenario: Owner as Reader/Writer

为了更方便地访问EHR数据，患者(比如Alice)可以将其所有EHR数据外包给远程医疗云。如图3所示，Alice(即数据所有者)将索引和EHR数据外包到云上，以便她可以随时随地使用手机和笔记本电脑进行搜索和访问。为了防止云从索引和存储数据中获取敏感信息，对索引和EHR数据进行了加密。当患者想要检索部分EHR数据时，她生成一个带有查询关键字的搜索令牌，并将其发送到云。使用搜索令牌对加密索引进行云搜索，并将匹配的加密数据返回给患者。

在这个场景中，患者是数据所有者，同时也是数据用户。也就是说，索引和EHR数据由同一人加密和检索。在这种情况下，可搜索对称加密方案适合于私有加密和搜索。在如图3所示的系统中，Alice用自己的秘钥对索引和EHR数据进行加密，并将其外包给云。当Alice想从云中访问某些信息时，她提交一个搜索令牌，这个令牌是根据查询的关键字由她的秘密密钥构造的。搜索令牌使云服务器能够定位所有EHR数据，以便索引项满足患者查询的关键字。

3.2 The Second Scenario: Single Reader/Single Writer

一般来说，病人(比如Alice)需要与她经常去看的全科医生共享她的EHR数据。如图4所示，Alice将索引和EHR数据外包到远程医疗云上，与她的全科医生等授权用户共享。考虑到病历的隐私，EHR数据和索引都应该以加密的形式存储在云端。在这种情况下，加密的索引应该同时支持关键字搜索和访问控制。只有授权用户，即Alice的全科医生，可以搜索索引并检索EHR数据。

 

公钥加密与关键字搜索(PEKS)可以用于实现这种一对一的EHR数据安全共享。具体来说，Alice用全科医生的公钥加密索引和她的EHR数据。当她的普通医生打算访问Alice的EHR数据时，他用自己的私钥生成一个与所查询的关键字相对应的搜索令牌，并将其发送到云。云使用搜索令牌搜索加密的索引，并将匹配的结果返回给全科医生。

SSE方案也可以在此场景中使用。但患者需要通过安全通道与全科医生共享密钥。这将导致额外的通信成本，并增加实际医疗保健应用程序中信息泄漏的风险。

3.3 The Third Scenario: One Writer/Many Readers

在某些情况下，患者(比如Alice)可能需要来自不同部门或护理提供组织(CDOs)的医生进行咨询治疗。请注意，邀请的从业人员是不同学科的专业人员，其中一些是专科医生，另一些是全科医生。在这样的小组协商中，每个参与者都需要获得Alice的EHR数据。如图5所示，Alice(即数据所有者)将索引和EHR数据外包给远程医疗云，以便与医院医生等多个授权用户共享。类似地，在外包给云计算之前，索引和EHR数据是加密的。在这种情况下，加密索引应该支持关键字搜索和细粒度访问控制。只有满足访问控制策略的用户才能搜索索引并访问Alice的EHR数据。

 

在这个场景中可以采用基于属性的关键字搜索(ABKS)来支持表达性搜索能力和细粒度访问控制。特别是，Alice使用访问策略加密索引，该访问策略指定了谁是授权用户(例如，医院1中的医生)。由于访问策略可能包含敏感信息，它们应该对云服务提供商或任何未经授权的用户隐藏，就像EHR数据和索引一样。这个系统中的每个用户都与一组属性相关联;例如，用户的属性包括名称、所属关系、职业等。当用户打算从云中获取某些信息时，用户根据查询到的关键字及其属性提交一个搜索令牌。搜索令牌使云服务器能够定位所有的EHR数据，使索引项满足查询的关键字和用户的属性满足预定义的访问策略。

在文献中，有两种与ABKS类似的加密方案，即基于属性的加密(ABE)和基于关键字搜索的公钥加密(PEKS)。ABE由Sahai和Waters[12]引入，并进一步发展成两种补充形式：密钥策略ABE (KP-ABE)，其中密文与访问控制策略[13]相关联，而ciphertextpolicy ABE (CP-ABE)，其中密文与访问控制策略[14]相关联。ABE中也存在许多具有隐藏访问结构的解决方案，包括谓词加密[15]和具有隐藏访问结构[16]的CP-ABE。PEKS由Boneh et al.[4]提出(详见第5节)，但是ABE和PEKS都不满足ABKS的要求；换句话说，它们不同时支持关键字搜索和访问控制。

3.4 The Fourth Scenario: Authorization Delegation

在特殊情况下，如患者(Alice)处于昏迷状态，需要紧急团体会诊或手术，团体会诊的每个参与者都需要访问Alice的EHR数据。而Alice此时无法授权自己的访问权限并与这些医生共享她的EHR数据。但总能搜索和访问她的EHR数据的全科医生可以通过重新授权搜索和访问权限与医生组共享这些数据。图6显示Alice(数据所有者)将其加密的EHR数据和索引外包到一个医疗保健云，与她的全科医生等授权用户共享。当Alice病情严重需要紧急集体会诊时，她的全科医生是唯一可以访问她的EHR数据的人，她将搜索和访问权限重新授权给会诊小组的医生。

在文献中，可以采用具有关键字搜索的代理重加密(PRES)来实现上述目标，其中搜索能力可以由授权用户授权。在这种情况下，不能采用PEKS和ABKS，因为它们不能重新授权授权用户的搜索和访问权限。

4 SEARCHABLE SYMMETRIC ENCRYPTION

可搜索对称加密(SSE)是一种加密原语寻址加密搜索，由Song等人在[1]中首次正式明确定义。为了使用SSE方案安全地存储和搜索数据库，客户端首先使用一种特殊的加密算法生成数据库的加密版本，包括加密的元数据，然后将其存储在云服务器上。之后，客户机可以与服务器交互，对数据库执行搜索并获得结果(这被称为对称设置，因为只有一个写入者同时也是数据库的读取者，即数据所有者，使用对称加密)。

4.1 Framework and Definitions of SSE

设Πsse =(Setup, Enc, TokenGen, Query)为关键字W集合上的SSE方案，由以下概率多项式时间(PPT)算法组成:

 

SSE方案正确性的基本概念是，对于所有安全参数λ和索引集，如果所有算法都执行正确，那么如果查询关键字w在索引集I中，服务器可以找到正确对应的加密文档:否则，服务器返回一个符号表示“未找到”，其概率不可忽略。

4.2 SSE Design: Security Measure

安全性是近十年来SSE研究的一个重要指标。第一个SSE方案[1]的安全概念被定义为针对选择的明文攻击(security against chosen plaintext attack，CPA)的安全性，也就是说，当只给出密文时，不受信任的服务器无法了解任何关于明文的信息。

2003年，Goh[5]首先提出了针对SSE的语义安全概念，即针对选择关键字攻击的语义安全(IND-CKA)。IND-CKA的安全模型旨在捕获这样一个概念，即对手A不能从其加密的索引中推断出文档的内容，除非它已经从以前的查询结果或其他通道中知道这些内容。粗略地说，游戏的工作方式如下:假设挑战者C给对手A两个相同长度的文档do和d1，每个文档都包含一些(可能不相等的)单词，以及一个索引。在这里，a的挑战是确定索引中编码了哪个文档。如果区分do和d1的索引是困难的，那么从索引中推导出至少一个do和d1没有共同之处的单词也一定是困难的。如果A不能确定索引中编码的文档与哪个文档的概率具有1/2不可忽略的不同，那么索引就不能显示其内容。Goh还引入了一种稍强的安全模型，称为IND2-CKA，通过改变IND-CKA游戏挑战阶段选择挑战子集的标准。

然后Curtmola等人[7](CGK+)指出，IND2-CKA并不是一个充分的安全概念，我们将其称为非适应性，只考虑对手使他们的搜索查询不考虑trapdoor和搜索结果以前的搜索。他们通过在自适应设置中引入不可区分性和基于模拟的定义来解决这个问题，即针对选择关键字攻击的自适应安全性(IND-CKA2)。SSE方案在自适应不可区分的意义上是安全的，如果任何两个adaptively-constructed历史以同样的长度和跟踪,(概率polynomialtime)对手无法区分一个历史视图的视图与可观的概率比其他的1/2。

[17]提出了通用组合(UC)模型(简称UCCKA2)中的IND-CKA2安全性，比标准IND-CKA2安全性更强。UC是一种通用模型，它认为协议仍然是安全的，即使它们与相同或其他协议的其他实例任意组合。

然而，在基于上述安全模型的方案中，对服务器的泄漏仅限于返回的(加密的)文档集和关于用户搜索模式[11]的统计信息，也就是说，他们用伪随机函数(prf)或伪随机排列(prp)生成的令牌是确定性的，也就是说，同一个关键字(SSW)总是生成相同的令牌。为了解决这一问题，[6]设计了一种基于谓词加密[15]、[18]的对称密钥仅谓词加密(SKPOE)方案，该方案具有概率令牌。他们考虑了一种新的安全概念，称为谓词隐私。谓词隐私的属性是令牌不显示关于已编码查询谓词的信息。SSW还为索引安全定义了明文隐私的安全概念，在前面的工作中称为IND-CKA。如果SSE方案同时实现谓词隐私和明文隐私，那么它就实现了完全的安全性，这允许除了访问模式之外不泄露任何东西。

4.3 SSE Efficiency: Single Equality Test

对于相等性测试，我们指的是对单个搜索关键字的精确关键字匹配。我们在这方面回顾了六项具有代表性的工作。

搜索加密数据的第一个实际方案是使用一个特殊的两层加密构造(SWP)[1]。其思想是分别加密每个单词，然后在密文中嵌入一个哈希值。为了进行搜索，服务器可以提取该散列值并检查该值是否具有这种特殊形式。他们的方案的缺点是必须使用固定大小的单词，而且加密和搜索算法的复杂性与每个文档的总单词数呈线性关系(即，最坏的情况)。

第二种方案[5]解决了SWP方案的一些局限性(例如，使用固定大小的字，搜索效率低)，它添加了一个bloom过滤器(BF)[19]作为每个文档的索引，它独立于底层加密算法。BF是一种数据结构，用于回答集合成员查询。通过为每个文档使用一个BF，搜索在文档数量上是线性的。使用BF的一个固有问题是可能出现假阳性。然而，通过适当的参数设置，假阳性概率可以降低到一个可接受的水平。

第三种方法[20](CM)提出了两种索引方案，它们使用一个预先构建的搜索关键字字典来构建每个文档的索引。索引是一个n位数组，初始设置为0，其中每个位位置对应于字典中的一个关键字。如果文档包含关键字，则将其索引位设置为1。CM-1和CM-2结构都只使用伪随机排列和伪随机函数。CM-1将字典存储在客户端，CM-2在服务器端加密。这两种结构都可以处理对文档集合的安全更新。搜索两种结构的时间与文档总数成正比。CM-2使用两轮检索协议，而CM-1只需要一轮搜索。

第四种方案[7](CGK+)提出了SSE的两种结构。它们添加一个反向索引，将搜索时间减少到包含关键字的文档数量。它们是第一个实现最优搜索时间的次线性方案。此外，这两种结构都使用一种特殊的数据结构(FKS字典[21])作为查找表。这使得索引更加紧凑，并将查找时间减少到O(1)。然而，由于数据的表示方式，更新的代价很高。因此，它们的方案更适合于不随时间变化的单片数据库。

另一种方法[22]被称为LSD+，它有两个方案提供高效的搜索和更新。搜索时间与服务器上存储的唯一关键字的数量成对数关系。LSD-1是一种交互式方案，需要两轮通信来生成、更新和搜索索引。LSD-2是非交互式的，它部署了一个散列链，但代价是更多的搜索计算。两种结构都是IND-CKA2安全的。

最后，Chase和Kamara [23] (CK)提出了一种基于SSE-1[7]的自适应安全结构。其思想是以填充和排列字典的形式生成一个反向索引。字典可以使用哈希表实现，从而获得最佳搜索时间。他们定义了IND-CKA2安全的泛化，其中可以通过泄漏函数影响确切的泄漏(例如，访问或搜索模式)。这使得该方案也可以对对手隐藏数据结构。然而，它们的实际构造仍然泄露了访问和搜索模式[11]。

4.4 SSE Efficiency: Conjunctive Keyword Search

为了提供真正实用的搜索功能，应该支持联合搜索，即给定一组关键字，查找包含所有这些关键字的所有文档。通过在以前的搜索结果中对每个单独的关键字执行搜索，可以将这个问题简化为单个关键字的情况。然而，这通常会导致低效搜索(例如，如果其中一个连词是gender=male，则会导致数据库大小的一半)和严重的泄漏(例如，它会显示匹配每个关键字的文档集)。在这方面，我们讨论了四项具有代表性的工作。

第一个作品[24](GSW)展示了如何为每个连接查询构建一组标记，这些标记可以针对文档关键字的编码版本进行测试，以识别匹配的文档。这些解决方案只泄漏匹配文档集(可能还有属性集)但是由于服务器产生的O(m)工作(m是数据库中文档或记录的数量)，因此不适合大型数据库。无论结果集的大小或匹配每个单个合词的文档数量，每次搜索都要付出这种代价。此外，这些解决方案需要O(m)通信和服务器与客户机之间的求幂，或者O(m)昂贵的配对操作(以及专用的加密假设)。这种方法的另一个严重的限制是，它只适用于结构化的属性-值类型数据库，不支持自由文本搜索。

第二种方法[25](BLL)开发了一个具有恒定通信和存储成本的合取关键字搜索方案。他们使用双线性映射来提高大型数据库所需的通信和存储成本。因此，BLL的通信比[24]中提出的两种方案都更高效，但其加密效率较低，因为它需要在文档中为每个关键字配置一个双线性映射。在随机oracle (RO)模型中，BLL在IND-CKA的扩展版本下被证明是安全的。

第三种方法[26](WWP)是第一种提出无关键字字段的合取关键字搜索方案的方法。其思想是通过使用每个关键字每个文档索引的双线性映射来删除关键字字段。与BLL方案一样，WWP搜索效率较低，因为它需要每个关键字每个文档索引的双线性映射。它在标准模型的IND-CKA扩展版本下也是安全的。

第四种方法[27](CJJ+13)是第一个提出SSE协议的方法，它支持对外包对称加密数据的合取搜索和通用布尔查询，并扩展到非常大的数据库和任意结构的数据，包括自由文本搜索。他们的解决方案在性能和隐私之间提供了一种现实可行的权衡，有效地支持非常大的数据库，但代价是向外包服务器适度且定义良好的泄漏(泄漏以数据访问模式的形式存在)。并且在DDH假设下，证明了其方案在广义定义下的INDCKA2是安全的，因此比前面的合取关键字搜索方案具有更高的安全性。

4.5 SSE Efficiency: Expressive Keyword Search

几个项目已经致力于支持更具表现力的关键字搜索，如模糊/相似关键字搜索[28],[29],[30],[31]，完全安全关键字搜索基于内积[6],[32],[33]，多关键字排名搜索[34],[35]，不幸的是，以较弱的安全保证为代价。

4.5.1 Fuzzy Keyword Search

Park等人[28](PKL+)提出了一种基于近似字符串匹配的方法来搜索加密数据中有错误的关键字。它们逐个字符加密一个词，并使用汉明距离搜索相似的关键字。他们提供了这种方法的两种构造。第一个构造更安全(即实现查询隐私)，而第二个构造更高效。

Adjedj等人[29](ABC+09)提出了一种生物特征识别的模糊搜索方案。他们使用位置敏感哈希(LSH)来确保来自同一个人的相似的生物特征读数被哈希到相同的值。对于汉明距离较小的输入，LSH输出具有相同哈希值的高概率。

Li等人[31](LWW+)提出了一种基于预先指定的相似语义使用编辑距离的模糊关键字搜索方案。其思想是预先计算模糊关键字集，每个关键字的编辑距离，并将它们加密存储在服务器上。搜索标记以相同的方式生成，这样服务器就可以测试相似性。他们的方案的搜索是交互式的，需要两轮来检索文档。

Kuzu等人的[30](KIK)提供了一种基于LSH和BF的通用相似度搜索构造。他们使用Jaccard距离来度量相似性搜索的距离。该协议也是交互式的，需要两轮通信来检索文档。

4.5.2 Full Secure Keyword Search Based on Inner Product

Shen等人[6](SSW)提出了一种基于内积的对称密钥谓词加密方案。它们将搜索标记和可搜索索引表示为向量，并在搜索阶段计算它们的内积。如前所述，它们给出了完全安全的定义，也就是说，该方案既实现了谓词隐私(搜索令牌不会泄露关于已编码查询谓词的信息)，又实现了明文隐私。点积可以对析取、多项式和CNF/DNF公式进行更复杂的计算。

Bósch等人[32](BTH+)提出了一个同样基于内积的方案。它使用Chang和Mizenmacher[20]的索引生成技术，结合了一些同态加密[36]。它们通过引入另一轮通信将查询阶段与文档检索分离开来。这使得BTH+更加灵活，并允许有选择地有效地检索文档。BTH+使用了基于晶格的密码系统[37]的最新优势，这使得BTH+比基于配对的方案更高效。

4.5.3 Ranked Keyword Search

Cao等人[35](CWL+)提出了保护隐私的多关键字排序搜索加密数据。在各种多关键字语义中，他们选择坐标匹配的有效相似度度量，即尽可能多的匹配，以捕获数据文档与搜索查询的相关性，并利用内积相似度对这种相似度度量进行定量评价。他们给出了两种基于安全内积计算的方案，以在两种不同的威胁模型中实现各种严格的隐私要求。

Sun等人[34](SWC+)提出了一种基于相似度排序的隐私保护多关键字文本搜索方案来解决这个问题。其思想是建立基于词频和具有余弦相似性度量的向量空间模型的搜索索引，以达到更高的搜索结果精度。为了满足强威胁模型下严格的隐私要求，他们提出了两种安全索引方案，即已知密文模型和已知背景模型。

4.6 Dynamic SSE for Incremental Update

SSE方案应支持安全地从加密文档集合中添加新文档或删除现有文档，在客户端在设置时生成加密数据之后，特别是在医疗保健云设置中，一旦创建了新记录，EHR数据应及时更新。

Song et al.[1]、Goh[5]和Chang[20]的构造都支持文档插入和删除，但需要线性搜索时间。Kamara等人[10](KPR)首先在次线性搜索时间引入了动态SSE (DSSE)方案，但它泄露了更新文档中所包含的唯一关键字的哈希值。Kamara和Papamanthou [9] (KP)方案通过增加用户数据结构的空间，克服了上述限制。

近年来，人们提出了一系列新的DSSE方案([8]、[33]、[38]、[41]、[42]、[43])，与[9]、[10]相比，[8]、[33]、[38]、[41]、[42]、[43])具有更好的索引大小和更新时间，信息泄漏更少。虽然这些方案逐渐改善，但也有缺点。

Stefanov等人[8](SPS)提出了一种实用的小泄漏动态可搜索加密算法。但是该方案在客户端需要很高的存储开销(例如，中等大小的文件关键字对需要210 MB)，客户端从服务器获取不可忽略的数据量，并对其执行无关排序。这个方案还需要服务器端的每个关键字文件对存储大量的数据(例如，1600位)。

Cash等人[38](CJJ+14)首次在超大型数据库中实现了动态对称可搜索加密方案。虽然与之前的工作相比，它的性能渐近地更好，但与[8]相比，它泄露的信息更多。注意，此工作中的数据结构随删除操作的数量线性增长，这最终需要重新加密数据结构。

Naveed等人[41](MMC)提出了一种不同于上述所有备选方案的方法，在这种方法中，服务器不执行任何处理，而只是充当存储和传输实体。该方案依赖于一种称为盲存储的原语。该方案虽然性能较好，但对交互的要求较高，这可能会给分布式客户端-服务器系统带来响应延迟。该方案比[38]泄漏的信息少，但只支持单关键字查询。

相比之下，Pappas等人的[42](PKV+)支持连接查询，但其更新功能不是无关的。作者通过周期性地重新加密整个索引来解决由于非无关更新造成的泄漏问题。

Yavuz等人[43](YGD+)提出了一种新的可并行的DSSE方案，该方案实现了更高的隐私性，即前向隐私、后向隐私、大小模式隐私和cka2安全，具有低信息泄漏、非交互和高效的更新以及对大文件关键字对的低客户端和服务器存储。他们的方案通过一个非常简单的数据结构(即两个静态哈希表支持的位矩阵)来实现这些属性，从而实现高效而安全的搜索/更新操作。然而，也由于使用了这种非常简单的数据结构，他们方案中的搜索令牌是确定性的，并泄露了用户的搜索模式。因此，他们的方案无法实现谓词隐私。

Zhang等人[33](ZXY+1)提出了一种高效的私有关键字搜索方案，该方案支持对基于反向索引的加密数据进行动态更新。他们的方案不仅支持二进制搜索(因此，搜索的时间复杂度从O(n^2)降低到O(log n)，其中n是关键字的数量)，而且还提供了更强的安全性概念:统计明文隐私和统计谓词隐私。这意味着该方案是安全的，即使对任何计算上没有边界的对手

4.7 Verifiable SSE: Ensuring Correctness

在云计算中，为了防止存储在云数据中心的外包数据被误用和滥用，例如故意删除数据或恶意意图，对于将敏感数据外包给第三方云存储托管服务的数据所有者来说，允许数据用户验证云服务器返回的搜索结果的正确性是至关重要的。此外，医疗保健云应该允许用户验证云是否忠实地执行了他们的搜索操作，同时保持外包数据的加密和对加密数据的查询的私密性。

考虑到云可能不会诚实地执行搜索操作并返回正确的结果，Chai和Gong [44] (CG)被认为是半诚实但奇怪的云服务器，它们只诚实地执行一小部分搜索操作，返回一小部分正确的搜索结果。

Kurosawa和Ohtaki [17] (KO12)首先研究了服务器是恶意的安全模型。他们提出了一种可验证的可搜索对称加密(VSSE)方案，其中他们使用消息认证码(MAC)来保护搜索结果的完整性。他们的方案在通用的可组合安全框架UC-secure中被证明是安全的。然而，它们的可验证SSE要求在数据文件数量上的搜索时间是线性的。

在此基础上，提出了[45]、[46]、[47]方案来增强vse。Wang等人[45](WMT)提出了一种基于符号树的可验证模糊关键字搜索方案。Kurosawa和Ohtaki [46] (KO13)演示了如何以可验证的方式更新(修改、删除和添加)文档。但以上两种方案只考虑了半诚实但好奇的云服务器，而不是恶意的云服务器。Cheng等人[47](CWG+)针对恶意云模型，提出了一种基于安全不可分辨混淆(iO)的可验证可搜索的对称加密方案。然而，iO在实际使用中是低效的。最近，Sun等人[40](SLL+)提出了一种SSE方案，使用户能够进行安全的合接关键词搜索，更新外包文档集合，高效地验证搜索结果的真实性。他们的计划的核实机制可委托给公众可信任的机构(电讯管理局)，或由数据用户自行执行。

4.8 Comparisons of Existing SSE Schemes

我们简要回顾了文献中提出的SSE方案。表1比较了这些SSE方案的六个重要指标:安全性、存储空间复杂度、搜索时间复杂度、查询类型、动态性和现有主要SSE方案的可验证性。

从表1可以看出，CJJ+14[38]方案比现有的其他SSE方案更实用，更适合于超大规模的数据库，具有效率高、关键词搜索表现力强、更新动态等优点。SLL+[40]方案比其他SSE方案更适合于不可信的公有云，因为它同时考虑了存储文档的可靠性和隐私性。ZXY+ 1[33]方案提供了比其他SSE方案更高的关键字隐私安全性。因此，它可以应用于小型数据库。

5 SEARCHABLE PUBLIC-KEY ENCRYPTION

使用关键字搜索的公钥加密(PEKS)是一种使用公钥系统对加密数据进行搜索的加密原语。与SSE不同，PEKS允许数据所有者将搜索能力授权给另一个用户，而无需通过安全通道将密钥发送给授权用户。以第3节中的第二个场景为例，数据所有者Alice使用全科医生的公钥使用加密算法加密她的EHR数据和索引，并将加密数据和加密索引外包到医疗保健云。她的全科医生Bob通过发送搜索令牌向云发出查询，该令牌是由令牌生成算法使用他的私钥创建的。通过搜索令牌和加密索引，云服务器可以定位匹配的EHR数据，而不了解存储的EHR数据的内容和用于提供搜索查询的关键字。

5.1 Framework and Definitions of PEKS

Boneh等人[4](BCO+)首先提出了PEKS的框架，并正式定义了其安全性，给出了从匿名身份加密(AIBE)到PEKS的一般转换。在这项工作之后，Abdalla等人[48](ABC+05)定义了PEKS中的一致性概念，并提供了从AIBE到PEKS的改进转换。

设Πpeks = (Setup, Enc, TokenGen, Query)是关键字集合W上的PEKS方案，由以下PPT算法组成:

 

与SSE的正确性概念类似，PEKS方案的正确性是对于所有安全参数a和索引集，如果所有算法都执行正确，则查询关键字w在索引集I中，服务器可以找到正确的对应加密文档;服务器以不可忽略的概率返回一个表示“未找到”的符号。

5.2 Security of PEKS

PEKS的传统安全概念称为INDPEKS- CKA安全，要求可搜索索引不泄露有关关键字的任何信息。但是，这种安全性并不能保证关键字从搜索令牌中泄漏。创建PEKS的挑战是实现令牌(或活板门)隐私。形式化令牌(或活门)隐私的安全模型的困难在于PEKS的验证功能，在公开密钥设置中，密文是由公开的已知参数创建的。这为任何对手提供了验证搜索令牌是否编码特定关键字的能力，这样就可以随时发动脱机字典攻击。

如前所述，搜索令牌关键字的隐私首先在对称密钥设置[6]和交互公开密钥设置[49]、[50]中讨论。Shen等人的[6](SSW)提出了一个安全概念——谓词隐私，以确保令牌不会泄露有关已编码查询谓词的信息。

在公开密钥设置中，Boneh等人[49](BKO+)提供了第一个方案，该方案在通信复杂度非常小的公开密钥设置中不显示关于用户搜索(包括访问模式)的任何部分信息

Camenisch等人[50](CKR+)提出了PEKS的一种扩展概念，称为带有无关关键字搜索的公开密钥加密(PEOKS)，用户可以从密钥持有者那里获得搜索令牌，而不需要透露关键字。

出于在公钥可搜索加密中提供谓词隐私的需要，Blundo等人[51](BIP)提出了一种带有部分公钥的谓词加密方案，并定义了令牌安全的概念，以确保令牌属性的隐私。

Zhu等人的[52](ZZR)扩展了PEKS以支持基于随机化思想的谓词隐私，而不需要接收者和潜在发送者之间的交互。

随后，Boneh等人[53](BRS)在函数加密中提出了函数隐私的新概念。他们的概念要求解密密钥实质上不透露其相应身份的信息，从而产生第一个可证明是关键字私有的公开密钥可搜索加密方案。然而，他们的方案是函数私有的，仅用于高度不可预测的身份(具有高最小熵)。

Nishioka[54]首先在PEKS框架内形式化了令牌隐私的概念，称为搜索模式隐私，即当给定两个令牌时，很难猜测它们是否对应同一关键字。

Arriaga等人[55](ATR)为IBE提出了密钥不可链接的安全概念，从而保证了PEKS中搜索令牌的隐私。然而，它们的格式都是在复合序组上构造的，这比在素数阶椭圆曲线[56]上需要更大的参数量和更长的时间来完成配对。

Zhang和Xue [57] (ZX)提出了一种高效的基于素数序组的关键字搜索公钥加密方案。他们的方案不仅有效地支持二进制搜索，从而使搜索复杂度从O(n)显著降低到O(log n)，其中n是关键字的数量，而且还具有很强的安全性概念，即统计IND-PEKS-CKA安全性和统计搜索模式隐私性。

5.3 PEKS Efficiency: Single Equality Test

在单一平等检验的背景下，为提高PEKS的效率作出了许多努力。我们在下面简要回顾几个具有代表性的方法。

Boneh等人[4](BCO+)提出了第一个使用公钥系统的可搜索加密方案。其思想是使用基于身份的加密(IBE)，其中关键字充当身份。此方案中的每个用户都允许使用收件人的公钥创建可搜索的内容。只有私钥持有者能够生成搜索令牌来在加密数据中进行搜索。

Abdalla等人的[48](ABC+05)形式化了匿名IBE (AIBE)，并通过将AIBE方案转换为可搜索的加密方案，提出了一个通用的SE结构。它们还提供了层级化的IBE (HIBE)转换，该转换允许使用临时关键字搜索(PETKS)将HIBE方案转换为公钥加密。其思想是生成一个只在特定时间间隔内有效的搜索令牌。当时间间隔包含在搜索令牌中时，服务器无法使用搜索令牌搜索时间间隔以外的密文。

Baek等人[58](BSS+)讨论了公共密钥加密(PKE)方案与PEKS方案结合所产生的问题。他们结合了ElGamal密码系统[59]、PEKS和[60]的随机重用技术，给出了一个具体的结构。它们还提供了对其方案的两个扩展，即多接收器设置和多关键字设置。

Crescenzo和Saraswat [61] (CS)提出了第一个PEKS方案，该方案不是基于双线性映射，而是基于Jacobi符号。其思想是使用cock基于身份的加密方案[62]的变换，该方案基于二次剩余问题。

Khader[63]提出了一种基于k-resilient IBE的方案[64]。其思想是利用从IBE构造PEKS方案的能力。Khader还给出了多个关键字的构造和安全无通道的PEKS方案。

Baek等人[65](BSS)在原来的PEKS[4]方案中消除了对安全信道传输活板门的需求。其思想是向PEKS中添加一个服务器公钥/私钥对，并使用Boneh等人[4]的聚合技术。通过添加服务器密钥对，只有发送方选择的服务器才能搜索。

Rhee等人[66](RPS+)增强了Beak等人[65]构建PEKS的安全模型，并构建了一个在增强模型中安全的PEKS方案。他们增强的安全模型允许攻击者获得密文和搜索令牌之间的关系。

Zhang和Imai [67] (ZI)使用了一种混合模型将PKE和PEKS组合成一个方案，对两个原语使用相同的密钥对。它们使用匿名IBE[68]和标签- kem /DEM(密钥/数据封装机制)[69]给出了一个通用构造和一个具体实例。

Tang和Chen [70] (TC)提出了带注册关键字搜索(PERKS)的公钥加密概念。他们的方案允许数据所有者仅为数据用户之前注册的关键字构建可搜索的内容。这使得他们的方案对离线关键字猜测攻击更加健壮。

5.4 Conjunctive and Expressive Keyword Search

在本节中，我们回顾了一些关于PEKS效率的研究成果，这些成果提供了支持连接关键字搜索和表达关键字搜索的PEKS实用结构。

Park等[75](PKL)研究了结合字段关键字搜索(PECKS)的公钥加密问题。它们提供了前两种结构，具有固定的搜索令牌大小，允许连接关键字搜索。

Hwang和Lee [76] (HL)提出了结合关键字搜索的公钥加密(PECK)，并引入了多用户PECKS (mpeck)的新概念。其思想是最小化服务器和用户的通信和存储开销。

Boneh和Waters [71] (BW)构建了PEKS方案，该方案支持基于隐藏向量加密(HVE)的比较查询、子集查询和任意合取查询[77]。

Shi等[72](SBC+)设计了一个支持多维范围查询的PEKS方案。他们用一组属性对消息进行加密。例如，在医疗保健应用程序中，属性是从业人员的字段，例如年龄、级别、部门等。在这些属性中，假设它们希望支持年龄a、级别l和部门d的数量的查询。权威机构可以向所有从业人员发出解密密钥在和范围内。使用此解密密钥，其元组在上述范围内可以被解密。

Bringer等[78](BCK)提出使用局部敏感哈希(LSH)来实现容错查询。LSH函数为类似的项目输出相同的哈希值，其中相似性以汉明距离衡量。他们将这些LSH值插入到一个Bloom过滤器中，并以加密的形式存储。如果两个关键字足够接近，则LSH输出相同的散列值，从而允许容错查询。

Sedghi等[79](SLN+)在HVE的基础上构造了一种可以用于通配符搜索加密的新方案。他们的方案允许在任何字母表上进行通配符搜索，而之前的方案[51]只能在二进制符号上工作。

Xu和Jin [73] (XJ)提出了一种新的允许模糊关键字搜索(PEFKS)的PEKS方案，该方案中，不可信服务器只获得模糊搜索trapdoor而不是精确搜索trapdoor，定义了选择关键字攻击下的语义安全性(SS-CKA)和非自适应选择关键字和关键字猜测攻击下的关键字不可分辨性(IK-NCK-KGA)。

5.5 Verifiable PEKS for Correctness

与SSE方案不同，PEKS的验证功能在文献中很少被研究，直到最近，Zhang等[74](ZXY+2)提出了一种新的可验证可搜索的非对称加密框架PVSAE。它为外包的加密数据提供了强有力的支持，在INDPEKS方面具有两个正式的安全属性——CKA安全性和搜索模式隐私。基于提出的框架，他们给出了两种具体的PVSAE方案。第一个方案“- pvsae”基于“-维向量”，实现了强大的安全概念，即统计IND-PEKS-CKA安全性和统计搜索模式私密性。第二种方案3-PVSAE是一种基于三维矢量的轻量化方案。PVSAE保持了强大的安全特性，并提供了对加密数据的高效搜索。

5.6 Comparison of Existing PEKS schemes

在本节中，我们从表2所示的六个重要指标对有代表性的PEKS方案进行比较:安全性、存储空间复杂度、搜索时间复杂度、查询类型、动态性和现有代表性PEKS方案的可验证性。

从表2可以看出，方案SBC+[72]可以支持表达性关键字搜索，但索引大小比方案BW[71]小。ZX[57]和ZXY+2[74]方案比现有的其他PEKS方案提供了更好的数据和关键字的安全性和私密性。而ZX15[57]具有更高的搜索效率，ZXY+2[74]提供了公开验证。

6 SEARCHABLE ATTRIBUTE-BASED ENCRYPTION

基于属性的关键字搜索加密(ABKS)是一种基于属性的加密系统对数据进行搜索的新型加密原语。它允许数据所有者将搜索能力授权给属性满足预定义访问策略的其他用户。同样，以第三个场景为例，数据所有者Alice在访问策略下使用ABKS算法加密索引的每个条目，并将它们以及编码的EHR数据外包到医疗保健云。属性满足访问策略的用户使用自己的私钥生成一个搜索令牌，并将其发送到云。通过搜索令牌和加密索引，云服务器可以定位匹配的EHR数据，而不了解存储的EHR数据的内容和关键字。在搜索过程中，只有属性满足访问策略的授权用户才能对编码后的EHR数据进行搜索，并获得正确的搜索结果(即对所查询的关键字生成有效的搜索令牌)。

Zhao等[80](ZNS)首先考虑使用基于属性的签名(ABS)来实现细粒度访问控制感知关键字搜索。然后，Wang等[81](WLL+)将PEKS与CP-ABE集成，提出了一种加密方案，称为ciphertext-policy - attribute -based encryption scheme with keyword search function (KSF-CP-ABE)。在他们的方案中，只有凭据满足访问策略的授权用户才能通过关键字搜索检索加密数据并解密密文。

6.1 Framework and Definitions of ABKS

基于属性的关键字搜索加密(ABKS)的概念最早是由Zheng等[82](ZXA)提出的。该原语允许数据所有者指定一种策略来控制对其外包加密数据的关键字搜索操作。也就是说，拥有满足数据所有者策略的属性的数据用户可以对我们来源的加密数据进行关键字搜索。这个原语自然有两种变体:KP-ABKS (key-policy ABKS)，其中加密凭据与访问控制策略关联;CP-ABKS (ciphertextpolicy ABKS)，其中密文与访问控制策略关联。为了统一表示，设IEnc表示对加密函数Enc的输入，IKeyGen表示对密钥生成函数KeyGen的输入。对于CP-ABKS, IEnc和IKeyGen分别是访问树和属性集;对于KP-ABKS, IEnc和IKeyGen分别是属性集和访问树。让F(IKeyGen,IEnc) = 1表示IKeyGen在CPABKS中满足IEnc, IEnc在KP-ABKS中满足IKeyGen。

设πabks = (Setup, KeyGen, Enc, TokenGen, Query)是基于关键字集合W的ABKS方案，Wλ由以下PPT算法组成:

ABKS方案正确性的概念是，如果所有算法都正确执行，并且用户的属性集满足预定义的访问策略，那么服务器总是可以找到由查询关键字索引的加密文档。

6.2 Security of ABKS

ABKS的对手模型如下:数据所有者和授权数据用户是可信的，但云是可信的，但很好奇(即，诚实地执行协议，但也试图推断隐私信息)。直觉上，安全意味着云除了搜索结果什么也学不到。具体来说，给定一个概率多项式时间对手A(云建模)，如果满足以下条件，ABKS方案是安全的:

(1)针对所选关键字攻击的选择性安全Selective security against chosen-keyword attack:在没有给予任何匹配搜索令牌的情况下，A不能在选择安全模型中推断出关于关键字密文的明文关键字的任何信息，其中A必须在系统启动之前确定它打算攻击的IEnc。

(2)关键字保密性Keyword secrecy:在公开密钥设置中，不可能对搜索令牌(aka)进行保护。谓词隐私[6])来防止关键字猜测攻击。这是因为A可以加密其选择的关键字，并检查生成的关键字密文和目标令牌是否对应于相同的关键字，这是由于使用确定性加密造成的。因此，Zheng等人[82]提出了一种较弱的安全概念，称为关键字保密，以确保从关键字密文和搜索令牌中学习关键字的概率a略大于正确的随机关键字猜测的概率。

(3)针对关键字猜测攻击的选择性安全Selective security against keyword guessing attack (KGA): Byun等人[25]所描述的KGA可以简单地表述为:如果关键字空间大小为多项式，则对手可以生成所有可能的关键字的密文。在获取搜索令牌时，对手可以通过全面测试所有密文来发起关键字猜测攻击。如果找到一个包含关键字的匹配密文，对手就会知道这个关键字就是与搜索令牌对应的那个。在ABKS方案中，访问结构也包含敏感的私有信息。如果关键字空间的大小是多项式，访问结构的暴露将导致ABKS方案容易受到脱机关键字猜测攻击。为了解决这一问题，Qiu等[83](QLS+)提出了一种新的原语隐策略ciphertextpolicy -based attribute-based encryption with keyword search (HPCPABKS)。使用此原语，如果数据用户的属性凭据不能满足数据所有者指定的访问控制策略，则数据用户无法在加密数据上搜索并了解有关访问结构的任何信息。

6.3 ABKS Verification and Efficiency

Zheng等人[82](ZXA)也提供了云返回结果的私人验证。但是，验证关键字的正确性是非常昂贵的。

Liu等[84](LWM+)提出了一种基于关键策略属性的关键字搜索(KPABKS)的高效构造方法，显著降低了验证的计算复杂度。

Sun等[85](SYL+)提出了一种基于属性的高效用户撤销关键字搜索方案(ABKSUR)，该方案可以有效地从当前系统中撤销用户，同时最小化对剩余合法用户的影响。他们的方案允许多个所有者独立加密数据并将其外包给云服务器。用户可以生成自己的搜索功能，而无需依赖始终在线的可信权威。

Yang[86]也专注于多发送者、多用户应用场景，提供了一种灵活的基于属性加密的同义词关键字搜索方案。

最近，Li等[87](LLZ+)开发了一种基于属性的加密方案，该方案具有外包发密钥和外包解密功能，可以实现关键字搜索功能。在该方案中，云服务提供商在不知道明文内容的情况下执行数据用户委托的部分解密任务。

6.4现有ABKS方案比较

表3对现有ABKS方案的安全性、查询类型、可验证性和用户撤销性进行了比较。从表3可以看出，SYL+[85]方案不仅提供了合词搜索，而且提供了可验证性和用户撤销性，安全性较强。QLS+[83]方案同时考虑了关键字的隐私性和访问策略，但不支持联合关键字搜索、可验证性和用户撤销。因此，SYL+[85]方案比现有的其他ABKS方案更适合于医疗保健应用。

7 SEARCHABLE PROXY RE-ENCRYPTION

代理重加密与关键字搜索(PRES)是一种加密原语，用于使用代理重加密系统对加密数据进行搜索。它允许授权数据用户通过重新加密外判数据，将搜索能力授权给其他用户。以第3节中的第4个场景为例，数据所有者Alice处于昏迷状态，需要紧急的小组会诊，小组会诊的每个参与者都需要访问Alice的EHR数据。而Alice不能在昏迷状态下授权这些医生在这个紧急时刻直接访问她的EHR数据。因此,她的全科医生,谁是一个授权用户搜索和访问她的EHR数据,并授权委托授权搜索和访问权限的医生在紧急的存在对爱丽丝EHR数据以及相关的搜索索引。

由Shao等[88]提出的PRES (SCL+)是第一种授权授权方案，允许一个数据用户将关键字搜索能力委托给另一个用户。但是，他们的PRES方案使用相同的加密算法加密消息和关键字。然后，Yau等[89](YPH+)提出了一种新的可搜索代理重加密方案(repeks)定义。它们扩展了PEKS的原始定义，包括重加密密钥生成算法和关键字密文重加密算法。该方法将消息加密和关键字加密分离开来，从而可以灵活地选择标准PRE和Re-Enc方案来满足实际应用的需求。

7.1 Framework and Definitions of PRES

让πpres = (Setup, KeyGen, ReKeyGen, Enc, ReEnc,TokenGen, Query)是一个双向，多用途，代理重加密与关键字搜索(PRES)方案由以下算法组成:

 

RPES方案的正确性意味着，如果所有算法都正确执行，那么服务器总是可以精确地搜索原始加密文档和重新加密的文档，并为用户找到正确的文档。

7.2 Security of PRES

Shao等[88](SCL+)为双向PRES提供了两个安全概念:关键字隐私和消息隐私。对于关键字隐私，对手可以获得任何密文的明文，几乎所有令牌(除了与两个指定关键字相关联的令牌)，但是，对手无法确定哪个关键字与给定的密文相对应。这个安全概念保证只有拥有令牌的人可以进行测试。对于消息隐私，允许对手获取除指定密文外的几乎所有密文的明文，并且所有的令牌，但它不能确定哪个消息与指定的明文对应。这种安全概念保证只有拥有私钥的人才能解密密文。

Yau等人[89](YPH+)定义了一种双向、多用途PRES方案的安全概念，称为双向、多用途PRES ca -security。这种安全概念要求对手在没有目标接收者或委托方的搜索令牌的情况下不能区分哪个关键字对应于给定的密文。像[88]一样，他们假设一个静态的腐败模型。

7.3 Anonimity, Efficiency and Delegation in PRES

Zhong等[90](ZWW+)和Fang等[91](FSG+)分别独立提出了基于关键字搜索的匿名条件代理重加密(CPRES)方案。这两种方案都实现了选择密文的安全性、关键字的匿名性、单向性、非交互性和抗合谋性。

Wang等[92](WHY+)进一步扩展了PRES，引入了一种新的原语:支持联合关键字搜索(CPRE-CKS)的受限单跳单向代理重加密。然而，前面所有的PRES解决方案都只考虑粗粒度访问控制的实施，即将搜索功能委托给一个特定的授权用户。

Shi等人[93](SLH+)考虑了细粒度访问控制实施，其中数据用户可以将搜索能力委托给多个用户。其思想是将基于属性的加密和代理重新加密相结合，允许数据所有者将关键字搜索能力委托给符合特定访问控制策略的其他数据用户。

7.4 Comparison of Existing PRES Schemes

表4从安全性、查询类型和多用户方面对现有PRES方案进行了比较。从表4中我们可以看出，只有SLH+[93]方案能够将关键字搜索能力委托给多个符合特定访问控制策略的用户。而其他PRES方案不能一次将搜索权限重新授权给多个用户。为了实现第四个场景的目标，他们需要重复这个方案。这使得它们在实际应用中非常低效。因此，SLH+方案[93]比现有的其他PRES方案更适合于第四个场景。

8 DISCUSSIONS ON IMPLEMENTATION

可搜索的加密功能可以作为云服务来实现和提供。对于集成可搜索加密的遗留SOA系统，一种方法是在其api中添加加密数据作为服务的关键字搜索。这个新服务可以在运行时调用以支持私有搜索操作。集成需要两个主要任务:(1)添加SE方案的功能组件，并将每个SE方案视为SOA系统的逻辑构建块。这将允许以与相同SOA框架下的任何其他服务相同的方式调用SE模式。(2)考虑到遗留SOA系统的访问控制策略可能不支持SE方案，需要在现有SOA系统的内部策略语言中添加SE控制访问作为新的访问控制策略。这将支持对特定用户访问的特定数据执行可搜索的加密。

Publicly Available Implementations. 尽管在SSE上发表了几十个作品，但只有少数开源软件包是公开可用的。Clusion[94]是一个SSE库，由布朗大学加密系统实验室的研究人员开发，易于使用。它的目标是提供各种最先进的SSE方案的模块化实现。结论包括处理单、析取、合取和(任意)布尔关键字搜索的结构。所有实现的方案在最坏情况下都具有次线性渐近搜索复杂度。另一个开源软件版本是Stefanov等人[95]在他们的工作[8]上发布的，但他们需要感兴趣的读者或研究人员通过电子邮件向作者请求一份代码副本。

对于PEKS、ABKS和PRES，不幸的是，我们没有找到公共领域的相关开源软件包。

9 RELATED WORK

理论上，可搜索加密也可以通过使用无关随机访问机(ORAM)和同态加密(HE)来实现。然而，这两种技术在实践中并不有效。我们将在相关工作部分简要回顾它们。

Oblivious RAM. ORAM的概念最早是由Goldreich和Ostrovsky[96]提出的，它可以用来隐藏SE中搜索和更新时的每次内存访问。目前已发表相关研究成果[8]、[97]、[98]、[99]、[100]、[101]、[102]、[103]、[104]等数十篇。ORAM提供了最强的安全级别(不仅是搜索模式隐私，还包括访问模式隐私)，即服务器只知道文档集合的大小。然而，由于大量的通信轮数和服务器端的存储成本，ORAM方案在实践中效率非常低。

Homomorphic Encryption (HE). 

HE是一种特殊类型的加密技术，可以在不解密的情况下对密文进行代数运算。这使得HE成为搜索加密数据的有趣工具，因为可以在加密数据上执行有意义的计算。大多数HE方案都支持对密文进行加法或乘法运算。Boneh等人[105]提出的基于配对的HE方案能够执行任意数量的加法和一次乘法。Gentry[106]提出的全同态加密(FHE)可以对加密数据进行任何有意义的计算，适用于查询加密数据。然而，当前的FHE方案在计算上非常昂贵，并且有很高的存储开销。对于某些应用，可以使用所谓的某种同态加密方案[107]。这些方案比FHE更有效，但只允许一定数量的加法和乘法。在医疗保健应用程序中使用某种或完全HE查询加密数据时，主要问题是生成的方案要求搜索时间与数据集长度成线性关系。在实践中，这对于许多关键任务应用来说太慢了。

Differential Privacy. 

由Cynthia Dwork在2006年提出的差异隐私[108]确保删除或添加单个数据库项不会(实质上)影响任何分析的结果[109]。当个人信息被用于次要目的时，差异隐私被用作保护个人信息的一般模型[110]，并被广泛研究用于保护隐私的健康信息发布[111]。但是，差异隐私仅适用于统计数据的隐私保护发布，并不适用于本调查中讨论的隐私但准确的数据检索和共享场景。

10 CONCLUSIONS

我们对医疗保健云应用程序的可搜索加密(SE)技术进行了调查。并对今后的研究方向进行了讨论。这篇论文有许多原创贡献。首先，我们已经将医疗保健用例描述为SE上下文中的四个场景。然后，我们分别提出了四种可搜索的加密技术来对加密后的EHR数据进行搜索。它们分别是可搜索对称加密(SSE)、关键字搜索公钥加密(PEKS)、关键字搜索属性加密(ABKS)和关键字搜索代理重加密(PRES)。如表5所示，我们一共分析了68个方案。相比之下，SSE在过去的研究中得到了更多的关注，并以更富表现力的搜索、更高的效率和更好的安全性得到了良好的发展。但是，SSE的应用场景比其他三个场景简单得多。请注意，在医疗保健应用程序中，最后三个场景(两个、三个和四个)在实践中更为常见。然而，随着应用场景变得更加复杂，关于ABKS和PRES的研究有些匮乏。构造一个结构良好的ABKS或PRES方案具有良好的功能，如表达性搜索、动力学和可验证性，已经证明是具有挑战性的。

我们推测未来在医疗保健云应用中部署可搜索加密技术的几个方向:首先，我们需要一些技术来提高SE方案的查询表达能力、效率和可扩展性，特别是对于PEKS、ABKS和PRES。因为所有现有的多用户SE方案在关键任务的现实世界应用程序所需的性能方面都不实用，而且不能很好地扩展到大型数据库。未来研究的另一个重要方向是为医疗保健云开发特定领域或问题场景驱动的SE方法，这可能会在特定搜索限制和数据隐私要求下屏蔽优化机会。