CN114946152A

CN114946152A - 用于在传输层安全和其它上下文中验证数据的分散式技术

Info

Publication number: CN114946152A
Application number: CN202080073715.3A
Authority: CN
Inventors: 张帆; 赛·克里希纳·迪帕克·玛拉姆; 哈贾斯利·马尔维; 史蒂文·戈德费德; 阿里·朱尔斯
Original assignee: Cornell University
Current assignee: Cornell University
Priority date: 2019-08-30
Filing date: 2020-08-28
Publication date: 2022-08-26
Also published as: AU2020336124A1; US20220377084A1; EP4022840A4; WO2021041771A1; EP4022840A1; KR20220069020A; JP2022546470A

Abstract

一个实施例中的验证器装置配置成经由一或多个网络与客户端装置和服务器装置通信。所述验证器装置参与与所述客户端装置和所述服务器装置的三方握手协议，其中所述验证器装置和所述客户端装置获得与所述服务器装置的安全会话的会话密钥的相应共享。所述验证器装置从所述客户端装置接收与所述服务器装置的所述安全会话相关的提交，且响应于接收到所述提交，向所述客户端装置释放与先前不可由所述客户端装置访问的所述安全会话相关的额外信息。所述验证器装置至少部分地基于所述提交和所述额外信息验证作为所述安全会话的部分由所述客户端装置从所述服务器装置获得的数据的至少一个表征的正确性。

Description

用于在传输层安全和其它上下文中验证数据的分散式技术

相关申请的交叉引用

本申请要求2019年8月30日提交且标题为“DECO：用于TLS的分散式预言机(DECO:Decentralized Oracles for TLS)”的美国临时专利申请第62/894,052号的优先权，所述专利申请的全部内容以引用的方式并入本文中。

政府支持声明

本发明是在美国政府支持下在美国国家科学基金会(NSF)的授权号CNS-1514163、CNS-1564102、CNS-1704615和CNS-1933655和陆军研究处(ARO)授权号W911NF161-0145下进行。美国政府拥有本发明的某些权利。

技术领域

本领域大体上涉及信息安全，包含例如用于证明数据来自特定来源或以其它方式验证在传输层安全(TLS)的上下文中和在其它上下文中获得的数据的正确性的技术。

背景技术

归功于TLS的广泛部署，用户可经由具有端到端机密性和完整性的信道访问私人数据。然而，用户无法做到的是向第三方证明这种数据的出处，即，其真正来自特定网站。现有方法引入非期望的信任假设或需要服务器侧修改。结果，将用户的私人数据的值锁定在其起源点中。

发明内容

说明性实施例针对TLS且在众多其它应用(其中必需或以其它方式需要证明数据是来自特定来源)中提供分散式预言机。

举例来说，一些实施例通过提供分散式预言机(在本文中说明性地称作DECO)克服现有方法的上述缺点，所述分散式预言机允许用户证明经由TLS访问的一块数据来自特定网站，和以零知识任选地证明关于这种数据的陈述，从而保持数据自身秘密。DECO可因此从集中式网络服务仓释放数据，从而使其可由丰富的应用程序访问。有利地，说明性实施例中的DECO在无可信硬件或服务器侧修改的情况下工作。

在一个实施例中，设备包括验证器装置，所述验证器装置包含处理器和耦合到所述处理器的存储器。验证器装置配置成经由一或多个网络与客户端装置和服务器装置通信。验证器装置参与与客户端装置和服务器装置的三方握手协议，其中验证器装置和客户端装置获得与服务器装置的安全会话的会话密钥的相应共享。验证器装置从客户端装置接收与服务器装置的安全会话相关的提交，且响应于接收到提交，向客户端装置释放与先前不可由客户端装置访问的安全会话相关的额外信息。验证器装置至少部分地基于提交和额外信息验证作为安全会话的部分由客户端装置从服务器装置获得的数据的至少一个表征的正确性。

应了解，前述布置仅为实例，且众多替代布置是可能的。

本发明的这些和其它实施例包含但不限于具有体现于其中的软件程序代码的系统、方法、设备、处理装置、集成电路和处理器可读存储媒体。

附图说明

图1展示说明性实施例中的实施用于TLS的分散式预言机的信息处理系统。

图2为说明性实施例中的用于实施用于TLS的分散式预言机的过程的流程图。

图3展示说明性实施例中的分散式预言机功能性的实例。

图4说明说明性实施例中的包括服务器装置、证明器装置和验证器装置的分散式预言机实施方案中的装置交互的多个阶段。

图5展示说明性实施例中的包括用于展现选择性开放和上下文完整性攻击的银行陈述信息的实例数据。

图6展示说明性实施例中的分散式预言机协议的一个可能实施方案的详细视图。

图7展示说明性实施例中的用于实施分散式预言机的三方握手协议的详细实例。

图8展示说明性实施例中的在证明器装置与验证器装置之间进行的建立密钥共享的协议。

图9和10展示说明性实施例中的结合分散式预言机的实施方案利用的协议的额外实例。

图11展示涉及两方的其中所述各方中的一个利用分散式预言机获得提供到智能合约的信息的智能合约实施例。

图12和13展示说明性实施例中的使用一或多个分散式预言机的相应揭示和修订(redact)模式来处理的实例数据。

图14展示说明性实施例中的用于独特密钥语法的两阶段解析的伪代码。

具体实施方式

本发明的实施例可以例如以包括计算机网络或网络、客户端、服务器、处理装置和其它组件的其它布置的信息处理系统的形式实施。本文中将详细地描述这种系统的说明性实施例。然而，应理解，本发明的实施例更一般地适用于广泛多种其它类型的信息处理系统和相关联的网络、客户端、服务器、处理装置或其它组件。因此，如本文所使用的术语“信息处理系统”意图广泛地理解为涵盖这些和其它布置。

图1展示说明性实施例中的实施用于TLS的分散式预言机的信息处理系统100。系统100包括多个客户端装置102-1、102-2……102-N和验证器装置104，所述客户端装置和所述验证器装置配置成经由网络105通信。客户端装置102中的给定一个可包括例如膝上型计算机、平板计算机或台式个人计算机、移动电话或另一类型的计算机或处理装置，以及多个这种装置的组合。验证器装置104可类似地包括各种类型的处理装置，每一处理装置包含至少一个处理器和耦合到所述至少一个处理器的至少一个存储器。

网络105可说明性地包含例如：全球计算机网络，例如因特网、广域网(WAN)、局域网(LAN)、卫星网络、电话或有线电视网络；蜂窝式网络，例如3G、4G或5G网络；使用例如蓝牙、WiFi或WiMAX的无线协议实施的无线网络，或这些和其它类型的通信网络的各种部分或组合。

系统100进一步包括与相应受保护数据源108相关联的多个TLS服务器106。TLS服务器106说明性地配置成控制对其相应受保护数据源108的访问。受保护的数据源108的至少一个子集说明性地包括相应的具有HTTPS函数的网站，其中HTTPS指代安全超文本传送协议，其为超文本传送协议(HTTP)的扩展。应了解，在其它实施例中可使用广泛多种额外或替代数据源。系统100的受保护数据源108在其可经由HTTPS通过TLS服务器106中的至少一个安全地访问的意义上受保护。其它数据源不必为可以这一特定方式访问的，且可实施额外或替代的访问控制机制，和/或可使用其它类型的安全协议公开地访问。

此外，尽管本文中的说明性实施例利用特定类型的一或多个服务器(例如TLS服务器106)，但应了解，其它类型的安全协议可在其它实施例中使用，且可在其它类型的服务器装置中实施。因此，如本文所使用的术语“服务器装置”意图广泛地理解，且不应视为以任何方式限于TLS服务器。

在一些实施例中，客户端装置102作为相对于系统100的验证器装置104或其它零知识证明(ZKP)预言机节点110的相应证明器装置来操作。因此，验证器装置104可视为系统100的ZKP预言机节点。因此，如本文广泛使用的术语的给定“验证器装置”可包括例如分散式预言机系统(例如系统100)的一组预言机节点中的特定预言机节点。

系统100中的装置和其它组件的特定数目、类型和布置仅作为说明性实例呈现，且可在其它实施例中变化。举例来说，尽管在这一实施例中仅展示单个验证器装置104，但其它实施例可包含多个验证器装置，如在其中其它ZKP预言机节点110作为相应验证器装置来操作的布置中。此外，TLS服务器106中的一或多个可各自配置成控制对受保护数据源108中的多个的访问。众多其它分散式预言机布置是可能的。

验证器装置104包括三方握手模块112、握手后交互模块114和证明验证模块116。这些模块实施分散式预言机协议的相应不同协议，在本文中也称作DECO协议，如下文更详细地描述。

在本实施例中，验证器装置104进一步包括处理器120、存储器122和网络接口124。假设处理器120经由图式中展示的简化说明性互连件以操作方式耦合到存储器122且耦合到网络接口124。

处理器120可以任何组合包括例如微处理器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、中央处理单元(CPU)、图形处理单元(GPU)、算术逻辑单元(ALU)、数字信号处理器(DSP)或另一类似处理装置组件，以及处理电路系统的其它类型和布置。由如本文所公开的给定处理装置提供的分散式预言机的功能性的至少一部分可使用这种电路系统实施。

存储器122存储用于由处理器120在实施处理装置的功能性的部分时执行的软件程序代码。举例来说，可使用存储在存储器122中的程序代码来实施模块112、114和116的功能性的至少部分。

存储这种程序代码以供对应处理器执行的给定这种存储器为本文中更通常称作具有体现于其中的程序代码的处理器可读存储媒体的内容的实例，且可以任何组合包括例如电子存储器，例如SRAM、DRAM或其它类型的随机存取存储器、只读存储器(ROM)、快闪存储器、磁性存储器、光学存储器或任何组合的其它类型的存储装置。

包括这种处理器可读存储媒体的制品视为本发明的实施例。如本文所使用的术语“制品”应理解为不包含暂时性传播信号。

在其它实施例中，可实施包括处理器可读存储媒体的其它类型的计算机程序产品。

另外，本发明的实施例可以包括处理电路系统的集成电路的形式实施，所述处理电路系统配置成实施与客户端装置102、验证器装置104、TLS服务器106和其它ZKP预言机节点110中的一或多个相关联的处理操作。

网络接口124配置成允许验证器装置104经由网络105与其它系统元件通信，且可包括一或多个常规收发器。

在操作中，在说明性实施例中，验证器装置104配置成参与与客户端装置102中的给定一个(例如客户端装置102-1)和TLS服务器106中的给定一个的三方握手协议。这种参与说明性地由验证器装置104的三方握手模块112控制。结合三方握手协议的执行，验证器装置104和客户端装置102-1获得与给定TLS服务器的安全会话的会话密钥的相应共享。安全会话说明性地包括TLS会话。

验证器装置104从客户端装置102-1接收与给定TLS服务器的安全会话相关的提交。响应于接收到提交，验证器装置104向客户端装置102-1释放与先前不可由客户端装置102-1访问的安全会话相关的额外信息。与提交相关的这些操作说明性地在握手后交互模块114的控制下进行。

验证器装置104至少部分地基于提交和额外信息验证作为安全会话的部分由客户端装置102-1从给定TLS服务器获得的数据的至少一个表征的正确性。这种验证说明性地在证明验证模块116的控制下进行。

在一些实施例中，验证器装置104进一步配置成响应于由客户端装置102-1从给定TLS服务器获得的数据的至少一个表征的正确性的验证而起始一或多个自动化动作。举例来说，验证器装置104可将验证信息或其它相关信息返回到客户端装置102-1。

作为实例，与安全会话相关的提交可包括对作为安全会话的部分由客户端装置102-1从给定TLS服务器获得的查询响应数据的提交。

作为另一实例，与安全会话相关的提交可包括对由客户端装置102-1结合三方握手协议建立但先前不可由验证器装置104访问的证明器密钥的提交。在其它实施例中，可使用其它类型的提交。

在一些实施例中，响应于接收到提交而向客户端装置102-1释放的额外信息包括由验证器装置104结合三方握手协议建立但先前不可由客户端装置102-1访问的验证器密钥。

在其它实施例中，验证器装置104进一步配置成结合客户端装置102-1与给定TLS服务器之间的交互作为客户端装置102-1的代理来操作，使得验证器装置104经由作为代理来操作的验证器装置104自动获得在客户端装置102-1与给定TLS服务器之间交换的密文作为安全会话的部分。这种实施例在本文中称作“代理模式”布置。

在一些实施例中，验证器装置104进一步配置成从客户端装置102-1接收表征作为安全会话的部分由客户端装置102-1从给定TLS服务器获得的数据的一或多个陈述。

举例来说，一或多个陈述中的给定一个说明性地包括作为安全会话的部分由客户端装置102-1从给定TLS服务器获得的查询响应数据的选择性揭示的子字符串。

作为另一实例，一或多个陈述中的给定一个说明性地配置成通过利用多阶段解析协议来提供上下文完整性，在所述多阶段解析协议中，作为安全会话的部分由客户端装置102-1从给定TLS服务器获得的查询响应数据由客户端装置102-1预处理以产生减少的数据，所述减少的数据随后由客户端装置102-1结合待由客户端装置102-1发送到验证器装置104的给定陈述的产生来解析。

可在其它实施例中使用表征作为安全会话的部分由客户端装置102-1从给定TLS服务器获得的数据的广泛多种其它类型的陈述。

在一些实施例中，结合三方握手协议，客户端装置102-1和验证器装置104与给定TLS服务器共同地建立一或多个共享会话密钥，其中客户端装置102-1具有一或多个共享会话密钥中的给定一个的第一共享，验证器装置104具有给定共享会话密钥的第二共享，且给定TLS服务器具有组合第一共享与第二共享的复合会话密钥。

另外或替代地，结合三方握手协议，客户端装置102-1从给定TLS服务器接收不可由验证器装置104访问的加密密钥。

在一些实施例中，验证器装置104和客户端装置102-1使用其与给定TLS服务器的安全会话的会话密钥的相应共享来协作，以产生由客户端装置102-1提供到给定TLS服务器的查询，以请求给定TLS服务器将数据发送到客户端装置102-1。

验证器装置104和客户端装置102-1可使用其与给定TLS服务器的安全会话的会话密钥的相应共享来协作，以验证由给定TLS服务器响应于查询而提供到客户端装置102-1的响应。

在一些实施例中，结合三方握手协议，客户端装置102-1和验证器装置104建立相应证明器和验证器密钥。在这种实施例中，验证作为安全会话的部分由客户端装置102-1从给定TLS服务器获得的数据的至少一个表征的正确性说明性地包括验证由客户端装置102-1提供到验证器装置104的证明。证明由客户端装置102-1至少部分地基于以下说明性地产生：(i)由客户端装置102-1结合三方握手协议建立的证明器密钥；(ii)由验证器装置104结合三方握手协议建立的验证器密钥；和(iii)客户端装置102-1的秘密信息，例如口令或密码。

在一些实施例中，验证作为安全会话的部分由客户端装置102-1从给定TLS服务器获得的数据的至少一个表征的正确性说明性地包括：获得从安全会话的至少一个密文的至少一部分导出的数据；和由客户端装置102-1验证数据的至少一个表征的正确性。如在这一上下文中和本文中的别处所使用的术语“密文”意图广泛地理解，且不应视为要求使用任何特定密码协议。

应了解，图1中所示的组件和其它系统元件的特定布置和如上文所描述的其相关联处理操作仅作为说明性实例呈现，且众多替代实施例是可能的。

举例来说，尽管系统100中的验证器装置104说明性地展示为包括耦合到存储器的处理器的单个处理装置，但在其它实施例中，验证器装置可包括分布式验证器装置，其中验证器装置104的功能性跨越多个不同处理装置分布。在这种实施例中，验证器在本文所公开的各种协议中的作用可跨越执行多方协议的多个不同方分布，其中每一这种方与分布式验证器装置的多个处理装置中的不同一个相关联。因此，如本文所使用的术语“装置”意图广泛地理解，从而涵盖包括耦合到存储器的处理器的至少一个处理装置，且因此涵盖如在分布式验证器装置的情况下的多个这种处理装置。

图2展示示范性过程，其至少部分地由与客户端装置102中的一个交互的验证器装置104说明性地实施为相对于由TLS服务器106中的一个控制的数据的证明器。应理解，这一特定过程仅为实例，且在其它实施例中可至少部分地由证明器、验证器和服务器实体进行额外或替代过程。

在这一实施例中，过程说明性地包括步骤200到208。如上所述，假设这些步骤的至少部分至少部分地由与客户端装置102中的一个交互且进一步涉及TLS服务器106中的一个的验证器装置104进行。这些组件在图2过程的上下文中还分别称作验证器、证明器和服务器。

在步骤200中，验证器参与与客户端和服务器的三方握手协议，其中客户端充当证明器。

在步骤202中，结合三方握手协议，验证器和证明器获得与服务器的安全会话的会话密钥的相应共享。

在步骤204中，验证器从证明器接收与服务器的安全会话相关的提交。

在步骤206中，响应于接收到提交，验证器向证明器释放与先前不可由证明器访问的安全会话相关的额外信息。

在步骤208中，验证器至少部分地基于提交和额外信息验证作为安全会话的部分由证明器从服务器获得的数据的至少一个表征的正确性。

众多其它技术可与如本文所公开的分散式预言机的实施方案相关联地使用。

因此，结合图2的流程图所描述的特定处理操作和其它功能性仅作为说明性实例呈现，且不应理解为以任何方式限制本发明的范围。替代实施例可使用涉及验证器装置、证明器装置和服务器装置的其它类型的处理操作。举例来说，过程步骤的排序可在其它实施例中变化，或某些步骤可与彼此同时而非依序地进行。此外，过程的多个例项可在系统100内针对相应证明器、验证器和服务器装置的不同集合彼此并行地进行。因此，系统100可使用本文所公开的技术同时实施大量分散式预言机。

现将参考图3到14描述说明性实施例的额外方面。

TLS的广泛部署允许用户可经由具有端到端机密性和完整性的信道访问私人数据。然而，用户在常规实践下无法容易地做到的是向第三方证明这种数据的出处，即，其真正来自特定网站。现有方法引入非期望的信任假设或需要服务器侧修改。

结果，将用户的私人数据锁定在其起源点处。用户无法在无来自当前数据持有者的帮助和许可的情况下将其数据以受完整性保护的方式导出到其它应用程序。

本文中的说明性实施例提供称作DECO(分散式预言机的缩写)的技术以解决这些和其它问题。DECO允许用户证明经由TLS访问的一块数据来自特定网站，和以零知识任选地证明关于这种数据的陈述，从而保持数据自身秘密。有利地，说明性实施例中的DECO可在不需要可信硬件或服务器侧修改的情况下实施。

DECO可从集中式网络服务仓释放数据，从而使其可由丰富的应用程序访问。为了展现DECO的效力，我们实施在无DECO的情况下难以实现的三个应用：使用智能合约的私人金融工具、将传统凭证转换为匿名凭证，和针对价格歧视的可验证声明。

应了解，本文中对DECO的这些和其它参考指代说明性实施例，且那些实施例的特定特征、功能性、优点和其它细节不应理解为以任何方式限制。替代实施例可实施用于验证TLS和其它上下文中的数据源的额外或替代技术。

如上文所指示，TLS为允许用户经由机密的受完整性保护的信道访问网络数据的强大的广泛部署的协议。但TLS具有严重局限性：其不允许用户向第三方证明她已访问的一块数据真实地来自特定网站。因此，数据使用通常限于其起源点，从而缩减了用户的数据可移植性，这是由最近的法规(例如GDPR)确认的权利。

具体来说，当用户经由TLS在线访问数据时，她无法在无来自当前数据持有者的帮助(因此，许可)的情况下安全地将其导出。因此，大量私人数据有意或无意地锁定在“深网”中，其为网络的不可公开访问的部分。

为了更好地理解所述问题，考虑Alice想要向Bob证明她已满18岁的实例。当前，年龄验证服务通常需要用户上传ID和详细个人信息，这引起隐私问题。但各种网站，例如公司支付记录或DMV网站，原则上存储且服务经过验证的出生日期。Alice可发送来自这个站点的她的出生日期的截屏，但这容易伪造。并且，即使截屏可以某种方式证明为真实的，也将泄漏信息(揭示她的准确出生日期)，不仅是她已满18岁。

预言机最初是为了向智能合约证明在线数据的出处而提出的，预言机为针对向具有出处和完整性保证的其它系统导出受TLS保护的数据的一个步骤。然而，现有方案具有严重的技术局限性。其仅对弃用的TLS版本起作用且不提供来自预言机的隐私(例如，TLSNotary)，或依赖于可信硬件(例如，Town Crier)，最近已针对所述情况出现各种攻击。另一类别的预言机方案假设服务器侧协作，从而委托服务器安装TLS扩展或改变应用层逻辑。服务器促进的预言机方案受两个基本问题困扰。首先，其打破传统兼容性，导致对较宽采用的显著障碍。此外，这种解决方案仅提供有条件的可导出性，因为网络服务器具有确定可导出哪些数据的独特自由裁量权(sole discretion)，且可随意审查导出尝试。允许用户导出其可访问的任何数据的机制将实现许多当前不可实现的应用。

为了解决以上问题，本文所公开的说明性实施例提供称作DECO的布置，即用于TLS的分散式预言机。不同于需要每个网站支持的预言机方案，DECO说明性地为来源不可知的且支持运行标准TLS的任何网站。不同于依赖于网站的参与的解决方案，DECO不需要服务器侧协作。因此，DECO的单个例项可使得任何人能够成为任何网站的预言机。

DECO使得丰富的因特网数据可以真实性和隐私保证由广泛范围的应用程序访问，包含无法接入因特网的应用程序，例如智能合约。DECO可通过为私人数据递送提供传送到第三方或公开发布的选项而从根本上改变当今的网络数据传播模型。这一技术能力突显了潜在的未来法律和法规挑战，但还预期创建和递送吸引人的新服务。重要的是，不同于一些替代方法，DECO并不需要可信硬件。

在一些实施例中，在高层级处，证明器提交一块数据D且向验证器证明D是来自TLS服务器

且任选地提交关于D的陈述π_D。再次参考证明年龄的实例，陈述π_D可为断言“D＝y/m/d为Alice的出生日期且当前日期-D为至少18年”。

不正式地，DECO实现真实性——验证器仅在确证关于D的陈述为真且D实际上从TLS服务器

获得时才确信。DECO还提供隐私，因为验证器仅学习陈述π_D对从

获得的一些D成立。

在使用传统TLS兼容的图元的同时，设计具有所需安全性和切实可行性能的DECO引入若干重要的技术挑战。一个挑战源于TLS产生由客户端(例如，DECO中的证明器)和网络服务器共享的对称加密和认证密钥的事实。因此，在用有效认证密钥对数据进行签名的意义上，客户端可伪造任意TLS会话数据。

为了解决这一挑战，DECO在证明器、验证器和网络服务器当中引入新颖三方握手协议，所述三方握手协议创建由证明器向验证器关于一块TLS会话数据D的不可伪造的提交。验证器可检查D真实地来自TLS服务器。从证明器的视角来看，三方握手在存在恶意验证器的情况下保持TLS的安全性。

有效选择性开放.在提交到D之后，证明器证明关于提交的陈述。尽管理论上可支持任意陈述，但我们针对可能最流行的应用程序进行优化——仅揭示对验证器的响应的子字符串。我们将这种陈述称作选择性开放。细粒度选择性开放允许用户隐藏敏感信息且减小后续证明的输入长度。

不成熟的解决方案将涉及使用通用零知识证明(ZKP)的TLS记录的昂贵可验证解密，但本文中的说明性实施例通过利用TLS记录结构实现量值级效率改进。举例来说，TLS记录的可验证解密的直接实施方案将涉及以零知识证明1024个AES调用的电路的正确执行，而通过利用CBC-HMAC的MAC接着加密(MAC-then-encrypt)结构，本文中的说明性实施例可仅用3个AES调用实现相同结果。

上下文完整性.选择性开放允许证明器仅揭示服务器的响应D的子字符串D′。然而，子字符串可取决于其出现的时间而意味着不同事物，且恶意证明器可通过断章取义来作弊。因此我们不仅需要证明D′出现在D中，还需要证明其出现在预期上下文中，即，D′相对于D具有上下文完整性。(应注意，这不同于隐私理论中的“上下文完整性”。)

如果会话内容经过结构化且可解析，那么可防止上下文完整性攻击。幸而大部分网络数据采取这一形式(例如，呈JavaScript对象符号(JSON)或超文本标记语言(HTML))。通用解决方案为解析整个会话且证明所揭示部分属于解析树的必要分支。但是，在网络数据通常满足的某些约束条件下，解析整个会话不是必要的。本文所公开的一些实施例提供新颖的两阶段解析方案，其中证明器预处理会话内容，且仅解析通常小得多的结果。我们从如在编程语言理论中所使用的程序的等效物的阐释中抽取，以构建关于两阶段解析方案的安全性的正式框架。本文所公开的说明性实施例提供用于特定语法的若干切实可行的实现。我们的定义和构造也一般化到其它预言机。举例来说，其可防止内容隐藏攻击的通用形式。

关于说明性实施例的实施方案和评估，我们设计且实施DECO作为完整的端到端系统。为了展现系统的效力，我们实施三个应用：1)使用智能合约的机密性保持金融工具；

2)将传统凭证转换为匿名凭证；和3)针对价格歧视的可验证声明。

我们对这些应用的实验展示DECO非常有效。举例来说，对于WAN设定中的TLS1.2，在线时间为2.85s以进行三方握手且为2.52s以用于2PC查询执行。对于上文所描述的应用，产生零知识证明花费约3s到13s。本文中的别处提供更多细节。

如结合待在下文详细描述的说明性实施例所公开的DECO有利地提供可证明安全分散式预言机方案。在一些实施例中，DECO提供用于现代TLS版本的预言机方案，其不需要可信硬件或服务器侧修改。

我们还在下文详细描述可使用DECO在零知识中有效证明的TLS记录的广泛类别的陈述。这种陈述允许用户仅开放会话数据提交的子字符串。优化实现优于通用ZKP的实质性效率改进。

关于上下文完整性攻击和缓解，我们识别对隐私保护预言机通用的新类别的上下文完整性攻击，且我们描述我们的涉及新颖有效两阶段解析方案的缓解方法。

传输层安全(TLS)

我们现在提供对TLS握手和记录协议的一些背景，在说明性实施例中，DECO在所述TLS握手和记录协议上构建。

TLS为在两个通信应用程序之间提供隐私和数据完整性的一系列协议。大致来说，其由两个协议组成：握手协议，其使用非对称密码术建立会话，从而建立用于下一协议的共享客户端和服务器密钥；记录协议，其中使用对称密码术以机密性和完整性保护传输数据。

握手.在握手协议中，服务器和客户端首先协定一组密码算法(也称作密码程序组)。其接着彼此认证(客户端认证任选)，且最后安全地计算待用于后续记录协议的共享秘密。

在说明性实施例中，DECO利用与短暂秘密的椭圆曲线迪菲－赫尔曼(Diffie-Hellman)(DH)密钥交换(ECDHE)，但这是作为实例而非限制。

记录协议.为了在TLS中传输应用层数据(例如，HTTP消息)，记录协议首先将应用程序数据D分段成固定大小的明文记录D＝(D₁,…,D_n)。每一记录通常填充到多个块(例如，128位)。记录协议接着任选地压缩数据，应用MAC，加密，且传输结果。对接收到的数据进行解密、验证、解压缩、重新组合，且接着递送到更高层级协议。特定密码操作取决于协商后的密码程序组。DECO支持两个常用模式下的高级加密标准(AES)密码：CBC-HMAC和GCM，其中CBC-HMAC指代密码块编链-基于散列的消息认证码，且GCM指代伽罗华(Galois)/计数器模式。关于TLS的这些和其它方面的额外细节可见于例如T.Dierks和E.Rescorla的“传输层安全(TLS)协议版本1.2”RFC 5246，2008，其以引用的方式并入本文中。同样，可在其它实施例中使用其它协议。

TLS 1.2与1.3之间的差异.在本文中的一些实施例中，我们集中于TLS 1.2，且稍后描述如何将我们的技术一般化到TLS 1.3。这里我们简要地注意这两个TLS版本之间的主要差异。TLS 1.3去除传统非AEAD密码的支持。握手流程也已重新构造。在ServerHello之后的所有握手消息现在都已加密。最后，使用不同密钥导出函数。额外细节可见于E.Rescorla的“传输层安全(TLS)协议版本1.3”RFC 8446，2018，其以引用的方式并入本文中。

多方计算

考虑n方的群组

其中的每一个保有一些秘密s_i。安全多方计算(MPC)允许其在不泄漏除f的输出外的任何信息的情况下共同地计算f(s_i,…,s_n)，即，

对s_j≠i毫不知情。MPC协议的安全性通常考虑破坏t个玩家且试图学习诚实玩家的私人信息的对手。两方计算(2PC)是指n＝2和t＝1的特殊情况。

存在对2PC协议的两种一般方法。加扰电路协议将f编码为布尔型(boolean)电路，这是最适合于逐位运算(例如，SHA-256)的方法。其它协议利用阈值秘密共享且最适合于算术运算。但在一些实施例中，我们使用2PC来计算的函数包含逐位和算术运算两者。我们将其分离成两个分量，且针对逐位运算使用优化后的加扰电路协议且针对算术运算使用基于秘密共享的MtA协议。关于在说明性实施例中使用的实例优化后的加扰电路协议的额外细节可见于Xiao Wang、Samuel Ranellucci和Jonathan Katz在ACM CCS，2017中的“认证加扰和高效恶意安全两方计算(Authenticated Garbling and Efficient MaliciouslySecure Two-Party Computation)”，其以引用的方式并入本文中。关于在说明性实施例中使用的实例基于秘密共享的MtA协议的额外细节可见于Rosario Gennaro和StevenGoldfeder在ACM CCS，2018中的“具有快速去信任设置的快速多方阈值ECDSA(Fastmultiparty threshold ECDSA with fast trustless setup)”，其以引用的方式并入本文中。这些仅为实例，且可在其它实施例中使用其它类型的协议。

我们现在陈述通过DECO的说明性实施例解决且呈现其架构的高层级概述的问题。

问题陈述：分散式预言机

本文中的说明性实施例提供用于构建“预言机”(即，可证明在线数据的出处和性质的实体)的协议。目标为允许证明器

向验证器

证明一块数据来自特定网站

和以零知识任选地证明关于这种数据的陈述，从而保持数据自身秘密。访问数据可需要来自

的私人输入(例如，口令)且这种私人信息应同样从

保持秘密。

我们在说明性实施例中集中于运行TLS的服务器，TLS为因特网上的广泛部署的安全协议程序组。然而，仅TLS并不证明数据出处。尽管TLS使用公开密钥签名用于认证，但其使用对称密钥图元来使用在每一会话的开始处建立的共享会话密钥来保护所交换消息的完整性和机密性。因此，知道这一对称密钥的

无法向第三方证明关于以密码方式认证的TLS数据的陈述。

网络服务器自身可例如通过仅对数据进行签名而假设预言机的作用。然而，服务器促进的预言机将不仅产生高采用成本，且使用户处于不利地位：网络服务器可对预言机能力强加任意约束条件。我们对其中任何人都可证明她可访问的任何数据的出处而不需要依赖于控制的单个中心点(例如提供数据的网络服务器)的方案感兴趣。

我们在说明性实施例中通过引入不依赖于可信硬件或来自网络服务器的协作的我们在本文中称作“分散式预言机”的事物来解决这些和其它攻击。所述问题比先前预言机有挑战得多，因为其妨碍需要服务器修改其代码或部署新软件或使用预测市场的解决方案，而同时通过支持对数据的任意断言而超出这些先前方法。

用于智能合约的认证数据馈送.本文所公开的说明性实施例的重要应用在于构建用于智能合约的认证数据馈送(ADF)，即，具有可验证的出处和正确性的数据。广泛多种其它应用有利地由本文所公开的技术支持。

在ADF的上下文中，由于智能合约无法参与2PC协议，因此其必须依赖于预言机节点以代表其作为

参与。因此，在一些实施例中，我们将DECO部署在分散式预言机网络中，其中一组独立操作的预言机可供智能合约使用。应注意，运行DECO的预言机仅对于完整性而不对于隐私是可信的。智能合约可进一步通过查询多个预言机且需要例如大多数协定而相对于完整性失效而对冲。我们强调即使所有预言机都被破解，DECO的隐私也得以保护。因此，DECO使得用户能够将从私人数据导出的ADF提供到智能合约，同时向预言机隐藏私人数据。

符号和定义

在一些实施例中，我们使用

来指代证明器，使用

来指代验证器且使用

来指代TLS服务器。我们使用粗体字母(例如，M)来指代向量且使用M_i来指代M中的第i元件。

我们使用如图3中所说明的理想功能性

来模型化预言机的基本性质。为了

的单独并行运行，所有消息都标记有以sid指代的独特会话id。在其它实施例中可使用额外或替代预言机性质。

如图3中所指示，在这一实施例中，

接受来自

的秘密参数θ_s(例如，口令)、查询模板Query和来自

的陈述Stmt。查询模板为获取

的秘密θ_s且返回完整查询的函数，其含有由

指定的公开参数。实例查询模板将为Query(θ_s)＝“GOOG在2020年1月1日的股票价格，其中API密钥＝θ_s”。证明器

可稍后证明发送到服务器的查询很好地形成(即，从模板构建)，而不揭示秘密。陈述Stmt为

想要评估服务器的响应的函数。按照先前实例，由于响应R为数字，所以下文陈述将比较其与阈值：Stmt(R)＝"R＞$1,000"。

在

承认查询模板和陈述(通过发送“好”和θ_s)之后，

使用从模板构建的查询检索来自

的响应R。我们假设诚实服务器，因此R为真实数据。

将Stmt(R)和数据源发送到

我们对不需要任何服务器侧修改或协作的分散式预言机中的这一实施例感兴趣，即，

遵循未修改的TLS协议。更特定来说，用于TLS的分散式预言机协议为三方协议

使得1)Prot实现

且2)

为标准TLS，可能连同应用层协议一起。

对手模型和安全性质.在说明性实施例中，我们考虑静态恶意网络对手

受损各方可从协议任意偏离且向

揭示其状态。作为网络对手，

从

学习消息长度，这是由于TLS未隐藏长度。我们假设

和

根据由

运行的应用层协议选择和协定适当的查询(例如，其应针对大部分应用为幂等的)和陈述。

对于给定查询

由

指代服务器的诚实响应。我们要求当

或

受损时保持安全。功能性

反映以下安全保证：

·证明器完整性：恶意

无法伪造内容出处，她也无法使得

接受无效查询或不正确地答复有效查询。具体来说，如果验证器输入(Query,Stmt)且输出

那么

必定已在TLS会话中将

发送到

从而接收响应

使得b＝Stmt(R)。

·验证器完整性.恶意

无法使得

接收不正确响应。具体来说，如果

输出(Q,R)，那么R必须为服务器对由

提交的查询

的响应，即，

·隐私：恶意

仅学习公共信息

和Stmt(R)的评估。

稻草人(Strawman)协议

我们在说明性实施例中集中于两个广泛使用的代表性TLS密码程序组：CBC-HMAC和AES-GCM。我们的技术也一般化到其它密码(例如，Chacha20-Poly1305等)。我们最初使用CBC-HMAC来说明某些实施例，且稍后描述用于AES-GCM的技术。

TLS针对每一通信方向使用单独的密钥。除非明确指定，否则我们不在两个之间进行区分且使用k^Enc和k^MAC指代用于两个方向的会话密钥。

在呈现DECO的说明性实施例时，我们以稻草人协议开始且逐渐地建立为完整协议。

实现

之间的

的稻草人协议如下。

查询服务器

且将发送到服务器和从服务器接收到的所有消息分别记录在

和

中。假设

和(k^MAC,k^Enc)为会话密钥。

她接着以零知识证明1)每一

解密为R_i‖σ_i、明文记录和MAC标签；2)用于R_i的每一MAC标签σ_i针对k^MAC进行验证；和3)所需陈述评估到响应(即，b＝Stmt(R))上的b。使用标准符号，

计算

∧验证(k^MAc,σ_i,R_i)＝1∧Stmt(R)＝b}。

她还证明

很好地形成为

如在证明p_q中类似，且将

发送到

在

为TLS会话的真实转录的条件下，证明器完整性性质似乎得以保持。直觉上说，CBC-HMAC密文绑定到底层明文，因此

可视为对会话数据的安全提交。也就是说，给定

仅可对独特消息开放(即，解密和MAC检查)。绑定性质防止

向除与服务器的初始会话外的不同消息开放

不幸的是，这一直觉为有缺陷的。稻草人协议完全失败，因为其无法确保

的真实性。证明器

具有会话密钥，且因此她可包含

中的任意消息的加密。

此外，零知识证明

需要构造涉及对整个转录进行解密和散列，这会过分昂贵。为了使协议切实可行，我们需要显著减低成本。

DECO的概述

上述稻草人方法的关键失败在于

在她提交到会话之前学习会话密钥。在DECO的说明性实施例中，从

扣留MAC密钥，直到她提交之后为止。

与服务器

之间的TLS会话必须仍提供机密性和完整性。此外，协议不得使性能降低到低于TLS的要求(例如，触发超时)。

图4展示说明性实施例中的包括服务器装置、证明器装置和验证器装置的实例DECO实施方案。在这一实施例中，DECO实施为三阶段协议。第一阶段为其中证明器

验证器

和TLS服务器

建立在

与

之间秘密共享的会话密钥的新颖三方握手协议。在握手之后为查询执行阶段，在其期间，

遵循标准TLS协议但在有来自

的帮助的情况下访问服务器。在

提交到查询和响应之后，

揭示她的密钥共享。最后，

在证明产生阶段中证明关于响应的陈述。

三方握手.基本上，

和

共同地充当TLS客户端。其协商具有呈秘密共享形式的

的共享会话密钥。我们强调这一阶段(类似于DECO的其余部分)对

完全透明，从而不需要服务器侧修改。

对于CBC-HMAC密码程序组，在三方握手结束时，

和

分别接收

和

同时

接收

如同标准握手，

和

两者获取加密密钥k^Enc。

三方握手可如下使得前述会话数据提交不可伪造。在会话结束时，

首先提交到

中的会话，如前所述，接着

揭示她的共享

从

的视角来看，三方握手协议确保(针对每一方向的)新MAC密钥用于每一会话，而不管潜在恶意证明器的影响如何，且密钥对

是未知的，直到她提交为止。在无MAC密钥的知识的情况下，

无法在提交到其之前伪造或篡改会话数据。DECO中的会话数据提交的不可伪造性因此降低了TLS中使用的MAC方案的不可伪造性。

可类似地支持其它密码程序组，例如GCM。在GCM中，单个密钥(针对每一方向)用于加密和MAC两者。握手协议类似地在

与

之间秘密共享密钥。本文中别处更详细地描述用于GCM的握手协议。

查询执行.由于会话密钥为秘密共享的，如所提及，所以

和

执行交互式协议以构造对查询进行加密的TLS消息。

接着将消息发送到作为标准TLS客户端的

对于CBC-HMAC，其计算查询的MAC标签，而对于GCM，其进行认证加密。应注意，查询对

为私人的且不应泄漏到

通用2PC对于较大查询将为昂贵的，因此我们改为引入比通用解决方案更高效量值级的定制2PC协议，如本文中别处所描述。

如先前所解释，

在接收到

的密钥共享之前提交到会话数据

从而使得提交不可伪造。接着

可验证响应的完整性，且证明关于其的陈述，如现将描述。

证明产生.使用不可伪造提交，如果

完全开放提交

(即，揭示加密密钥)，那么

可通过检查解密的MAC容易地验证

的真实性。

然而，揭示用于

的加密密钥将破坏隐私：其将揭示在

与

之间交换的所有会话数据。理论上，

可改为以零知识(即，在不揭示加密密钥的情况下)证明

上的任何陈述Stmt。但是，通用零知识证明技术对于Stmt的许多固有选择将过分昂贵。

DECO改为引入支持针对广泛一般类别的陈述的高效证明的两种技术，即在本文中称作TLS会话转录的“选择性开放”的技术。选择性开放涉及向

揭示子字符串或修订(即，切除)子字符串，从而向

隐藏所述子字符串。

图5展示充当证明器的用户Bob的简化JSON银行陈述作为说明性实例。这一实例将用于展现选择性开放和上下文完整性攻击。假设Bob

想要向

揭示他的支票账户余额。揭示用于他的TLS会话的解密密钥将为非期望的：其还将揭示整个陈述，包含他的交易。替代地，使用本文所公开的技术，Bob可高效地仅揭示在第5到7行中的子字符串。替代地，如果他不在意揭示他的储蓄账户余额，那么他可在第7行之后修订他的交易。

两个选择性开放模式(揭示和修订子字符串)为有用的隐私保护机制。其还可充当用于后续零知识证明的预处理。举例来说，Bob可能想要证明他有余额大于$1000的账户，而不揭示实际余额。他将接着以零知识证明包含他的支票账户余额的子字符串上的断言(“余额>$1000”)。

然而，仅选择性开放对于许多应用是不够的。这是因为子字符串的上下文影响其含义。在没有我们称作上下文完整性的事物的情况下，

可作弊且揭示错误地表现为向

证明声明的子字符串。举例来说，Bob可能没有高于$1000的余额。但是，在查看他的银行陈述之后，他可在同一TLS会话中向客户服务发布具有子字符串“余额”：$5000的消息，且接着查看他的待决消息(呈反射攻击形式)。他可接着揭示这一子字符串以欺骗

对证明器供应的去往

的输入的各种净化启发法(例如，截断会话转录)可潜在地防止一些这种攻击，但与其它形式的网络应用程序输入净化一样，其为脆弱的且易于受攻击。

替代地，我们引入严密的技术，通过所述技术明确地但秘密地解析会话数据。我们将这一技术称作“零知识两阶段解析”。根据这一技术，

在第一阶段中本地地解析

且接着以零知识向

证明关于对所得子字符串的约束条件的陈述。举例来说，在我们的银行实例中，如果银行供应的密钥值存储区始终用区分字符λ转义，那么Bob可通过经由本地解析且向

揭示前面是λ的子字符串“余额”：$5000而提取来证明正确余额。可展示，对于极常见类别的网络API语法(独特密钥)，这一二阶段方法产生比更通用技术高效得多的证明。

图6展示上文介绍的DECO协议的更详细实例实施方案。在这一实施例中，DECO协议包括三方握手阶段，其后接用于查询执行阶段的2PC协议，和证明产生阶段。下文将更详细地描述这些阶段中的每一个。应了解，这一实施例的特定细节(与本文所公开的其它实施例一样)仅作为实例呈现，且不应理解为以任何方式限制。本领域的技术人员将认识到，可使用额外或替代技术。

三方握手

在一些实施例中，三方握手(3P-HS)的目标为以对

完全透明的方式在证明器

与验证器

之间秘密共享在与服务器

的TLS会话中使用的会话密钥。我们首先集中于阐述CBC-HMAC，接着调适所述协议以支持GCM。

图7展示说明性实施例中的三方握手协议的正式规范。

图8展示一些实施例中的作为三方握手协议的部分的实例ECtF协议。

同样，这些协议的特定细节仅为实例，且不以任何方式限制。举例来说，在其它实施例中，可使用涉及证明器、验证器和服务器的广泛多种其它类型的三方握手协议。因此，如本文所使用的术语“三方握手协议”意图广泛地理解。

如同标准TLS握手，3P-HS包含两个步骤：第一，

和

计算通过TLS兼容的密钥交换协议与服务器共享的秘密

的相加共享。这里推荐和聚焦于ECDHE，但其它技术可用于计算共享；第二，

和

通过用其Z的共享作为输入安全地评估TLS-PRF而导出秘密共享的会话密钥，其中PRF指代伪随机函数。下文我们给出文本描述，因此不需要正式规范来理解。

步骤1：密钥交换.假设

指代在ECDHE中使用的EC群组且G指代其产生器。

证明器

通过将常规TLS握手请求和随机临时值r_c发送到

(在ClientHello消息中)来起始握手。在从

接收到证书、服务器临时值r_s和带符号短暂DH公钥

(在服务器问候(Server-Hello)和ServerKeyExchange消息中)后，

检查证书和签名且将其转发到

在进行相同检查之后，

对秘密s_V进行采样且将DH公钥Y_V＝s_V·G的她的部分发送到

其接着对另一秘密s_P进行采样且将组合的DH公钥Y_P＝s_P·G+Y_V发送到

由于服务器

运行标准TLS，所以在

(和

)将其Z的共享计算为Z_P＝s_P·Y_S(和Z_V＝s_V·Y_S)时，

将计算DH秘密。应注意Z＝Z_P+Z_V，其中+为

的群组运算。假设所选择群组中离散对数问题为困难的，那么Z对任一方都是未知的。

步骤2：密钥导出.现在

和

已建立Z的相加共享(呈EC点形式)，其通过评估以Z的x坐标带密钥的TLS-PRF来导出会话密钥。

这里的技术挑战为在2PC中协调算术运算(即，

中的加法)与逐位运算(即，TLS-PRF)。众所周知，布尔型电路并不很好地适合于大域中的算术。作为具体估计，仅产生x坐标的EC点加法涉及4个减法、一个模反转和2个模乘法。基于非常优化后的电路的对AND复杂度的估计产生仅用于减法、乘法和模归约的超过900,000个AND门——甚至不包含反转，其将需要在电路内部运行扩展欧几里德(Euclidean)算法。

归因于在布尔型电路中添加EC点的过高成本，

和

使用展示于图8中的ECtF协议将

中的EC点的相加共享转换为其在

中的x坐标。接着布尔型电路仅涉及在

中添加两个数字，这可仅用～3|p|AND门进行，其为我们的实施方案中的～768AND栅极，其中p为256位。

使用ECtF的共享转换.ECtF协议将

中的共享转换为

中的共享。到ECtF协议的输入为两个EC点

标示为P_i＝(x_iy_i)。假设(x_s,y_s)＝P₁★P₂，其中★为EC群组运算，那么协议的输出为

使得α+β＝x_s。特定来说，对于我们考虑的曲线，x_s-λ²-x₁-x₂，其中λ＝(y₂-y₁)/(x₂-x₁)。可类似地计算y_s的共享，但我们省略所述计算，这是由于TLS仅使用x_s。

ECtF使用相乘对相加(MtA)共享转换协议作为构建块。我们使用α，β：＝MtA(α，b)来指代MtA分别以输入α和b在Alice与Bob之间的运行。在运行结束时，Alice和Bob接收α和β，使得a·b＝α+β。可将协议一般化以处置向量输入而不增加通信复杂度。即，对于向量

如果α，β：＝MtA(α，b)，那么(α，b)＝α+β。

现在我们描述ECtF的协议。ECtF具有两个主要成分。假设[α]指代α的2个共享中的2个，即，[α]＝(α₁，α₂)，使得i方具有用于i∈{1，2}的α_i，同时α＝α₁+α₂。第一成分为共享反转：给定[α]，计算[α^-1]。这可如下进行：i方对随机值r_i进行采样且执行MtA以计算δ₁，δ₂：＝MtA((α₁，r₁)，(r₂，α₂))。应注意，δ₁+δ₂＝α₁·r₂+α₂·r₁。i方公布v_i＝δ_i+α_i·r₁，且因此两方学习v＝v₁+v₂。最后，i方输出β_i＝r_i·v^-1。协议计算α^-1的正确共享，因为β₁+β₂＝α^-1。此外，协议不向假设MtA为安全的任何方泄漏α。实际上，i方的视图由(α₁+α₂)(r₁+r₁)组成，其由于r_i为均匀随机的而为均匀随机的。

第二成分为共享乘法：计算[αb]，给定[α]，[b].[αb]可使用MtA计算如下：各方执行MtA以计算α₁，α₂，使得α₁+α₂＝α₁·b₂+α₂·b₂。接着，i方输出mi＝α_i+α_i·y_i。协议的安全和正确性可类似如上而论证。

TLS-PRF的安全评估.在已计算ECtF中的Z的x坐标的共享(所谓的TLS中的预主(premaster)秘密)的情况下，

和

评估2PC中的TLS-PRF以导出会话密钥。使用已知SHA-256电路，我们手动优化TLS握手电路，从而产生具有779,213的总AND复杂度的电路。

调适以支持GCM.对于GCM，单个密钥(针对每一方向)用于加密和MAC两者。在TLS1.2中调适以上协议以支持GCM是简单的。第一步骤将保持相同，而第二步骤的输出需要截断，因为GCM密钥更短。

调适TLS 1.3.为了支持TLS 1.3，3P-HS协议必须适于新握手流程和不同密钥导出电路。值得注意的是，在ServerHello之后的所有握手消息现在都己加密。不成熟的策略将为在2PC中解密所述消息，这将是昂贵的，因为证书通常较大。然而，归功于TLS 1.3的密钥独立性性质，我们可构造与TLS 1.2的复杂度类似的3P-HS协议，如本文中别处所描述。

查询执行

在握手之后，证明器

将她的查询

发送到作为标准TLS客户端的服务器

但借助于来自验证器

的帮助。特定来说，由于会话密钥是秘密共享的，所以双方需要交互且执行2PC协议以构造TLS记录加密

尽管通用2PC将在理论上足够，但对于较大查询其将为昂贵的。我们改为引入更高效量值级的定制2PC协议。

我们首先集中于一回合会话，其中

在接收到任何响应之前将所有查询发送到

DECO的大多数应用(例如，证明经由HTTP GET检索到的内容的出处)为一回合的。扩展DECO以支持多回合会话在本文中别处描述。

CBC-HMAC.记住

和

保存MAC密钥的共享，同时

保存加密密钥。为了构造TLS记录加密

(潜在地对

为私人的)，双方首先运行2PC协议以计算

的HMAC标签τ，且接着

在本地加密

且将密文发送到

假设H指代SHA-256。记住具有密钥k的消息m的HMAC为

术语ipad和opad指代在HMAC算法中利用的相应“内部”和“外部”值。直接2PC实施方案对于较大查询将为昂贵的，因为其需要在2PC中对整个查询进行散列以计算内部散列。这通过在

本地(即，在无2PC的情况下)进行内部散列的计算而有利地在说明性实施例中避免。如果

知道

那么她可计算内部散列。但是，我们无法简单地将

给到

因为她可接着学习k且伪造MAC。

我们的优化利用SHA-256中的梅克尔-达姆加德(Merkle-

)结构。假设m₁和m₂为两个正确设定大小的块。那么将H(m₁‖m₂)计算为f_H(f_H(IV,m₁),m₂)，其中f_H指代H的单向压缩函数，且IV指代初始向量。

图9展示用于CBC-HMAC的握手后协议。

在三方握手之后，

和

执行简单2PC协议以计算

且将其向

揭示。为了计算消息m的内部散列，

仅使用s₀作为IV来计算m的散列。揭示s₀并不揭示k^MAC，因为假设f_H为单向的。为了计算HMAC(k,m)，接着涉及计算内部散列上的2PC中的外部散列，其为短得多的消息。因此，与具有通用2PC的每一记录中的多达256个SHA-2块相比，我们能够在不考虑查询长度的情况下将2PC计算的量减少到几个块。

AES-GCM.对于GCM，

和

进行

的认证加密。2PC-AES利用优化后的电路是简单的，但针对较大查询计算标签为昂贵的，因为其涉及针对每一记录评估大域中的长多项式。我们的优化后的协议经由预计算在本地进行多项式评估，如本文中别处更详细地描述。由于2PC-GCM不仅涉及标签创建且还涉及AES加密，所以其引发比CBC-HMAC更高的计算成本和等待时间。

本文所公开的其它实施例利用高效的替代协议(称作代理模式协议)，其在额外信任假设下完全避免握手后2PC协议。

如图6中所示的完整DECO协议中所说明，在查询服务器且接收到响应之后，

通过将密文发送到

而提交到会话，且接收

的MAC密钥共享。接着

可验证响应的完整性，且证明关于其的陈述。图6指定用于CBC-HMAC的完整DECO协议。用于GCM的DECO协议为类似的且在本文中别处描述。

为了清晰起见，我们抽取掉理想功能性

中的零知识证明的细节。在从

接收到(“证明”，x,w)后，在x和w分别为私人和公开见证的情况下，

将w和关系π(x,w)∈[0,1}(在下文定义)发送到

特定来说，对于CBC-HMAC，x,w,π定义如下：

和

关系π(x,w)当且仅当(1)

(和

)为

(和R)在密钥k^Enc,k^MAC下的CBC-HMAC密文；(2)

且(3)Stmt(R)＝b时输出1。否则其输出0。

假设用于安全2PC和ZKP的功能性，其可展示如图6中所说明的Prot_DECO针对恶意对手UC安全地实现图3的

更特定来说，假设离散记录问题在三方握手中使用的群组中为困难的，且f(SHA-256的压缩函数)为随机预言机，那么Prot_DECO针对具有中止的静态恶意对手UC安全地实现

混合世界中的

用于GCM的协议具有类似流程。上文描述了三方握手和查询构造协议的GCM变型。

图10展示GCM变型中的用于验证标签和对记录进行解密的2PC协议。这些也称作用于GCM的握手后协议。

不同于CBC-HMAC，GCM不提交：对于以密钥k加密的给定密文

知道k的人可高效找到在传递完整性检查时将

解密为不同明文的k′≠k。为了防止这种攻击，我们需要

在学习

的密钥共享之前提交到她的密钥共享

在证明产生阶段中，除证明关于

和R的陈述之外，

还需要证明用于解密

和

的会话密钥针对

的提交是有效的。GCM变型的安全的证明类似于CBC-HMAC的证明。

证明产生

记住证明器

提交到TLS会话的密文

且向

证明明文M满足某些性质。在不损失一般性的情况下，我们假设

和M仅含有一个TLS记录，且此后将其称作密文记录和明文记录。可通过针对每一记录重复协议来处置多记录会话。

仅证明M的出处是简单的：仅揭示加密密钥。但这牺牲隐私。替代地，

可使用一般零知识技术证明关于M的任何陈述。但这种证明常常是昂贵的。

在以下描述中，我们呈现针对实例应用优化后的两个类别的陈述：仅揭示响应的子字符串同时证明其出处(“选择性开放”)，或进一步证明揭示的子字符串出现在由

预期的上下文中(“通过两阶段解析的上下文完整性”)。

选择性开放.说明性实施例实施在本文中称作“选择性开放”技术的技术，其允许

高效揭示或修订明文中的子字符串。假设明文记录由信息块M＝(B₁,…,B_n)构成(成块的细节在下文论述)。选择性开放允许

证明M的ith信息块为B_i，而不揭示M的其余部分；我们将这称作揭示模式。还可证明M_-i与M相同，但具有去除的信息块。我们将这称作修订模式。两种模式都是简单的，但可用于切实可行的隐私目标。选择性开放的粒度取决于密码程序组，我们现在论述所述密码程序组。

CBC-HMAC.记住对于证明产生，

保存加密和MAC密钥k^Enc和k^MAC两者，而

仅具有MAC密钥k^MAC。我们的性能分析假设具有SHA-256和AES-128的密码程序组，其匹配我们的实施方案，但所述技术适用于其它参数。记住使用MAC接着加密：明文记录M含有多达1024个AES数据块和3个MAC标签块σ，我们将其指代为M＝(B₁,…B₁₀₂₄,σ)，其中σ＝(B₁₀₂₅,B₁₀₂₆,B₁₀₂₇).

为M的CBC加密，由相同数目个块组成：

其中

揭示TLS记录.证明

在不揭示k^Enc的情况下加密M的不成熟方式为证明ZKP中的每一AES块的正确加密。然而，这将需要ZKP中的多达1027个AES调用，从而产生不可行性能。

利用MAC接着加密结构，可仅使用ZKP中的3个AES调用进行相同操作。这说明性地涉及证明

的最后几个块加密标签σ且直接揭示明文。特定来说，

计算

且将(M,π)发送到

接着

验证π且检查M上的MAC标签(应注意，

知道MAC密钥)。其安全依赖于HMAC中的底层散列函数的抗冲突性，即，

无法找到具有相同标签σ的M′≠M。

揭示具有修订后的块的记录.假设ith块含有

想要修订的敏感信息。直接策略为通过计算证明B_i-＝(B₁,…,B_i-1)和B_i+＝(B_i1+,…,B_n)形成通过

加密的明文的前缀和后缀

但这是昂贵的，因为其将涉及ZKP中的3AES和256SHA-256压缩。

利用SHA-256的梅克尔-达姆加德结构，若干优化是可能的。假设f指代SHA-256的压缩函数，且s_i-1指代在B_i-上应用f之后的状态。首先，如果可例如在B_i含有例如API密钥的高熵数据时揭示s_i-1和s_i两者，那么可仅使用ZKP中的1SHA-256实现以上目标。为了这样做，

计算π＝ZK-PoK{B_i：f(s_i-1,B_i)＝s_i}且将(π.s_i-1,s_i,B_i-,B_i+)发送到

其接着1)通过从B_i-对其进行重新计算来检查s_i-1；2)验证π；且3)通过从s_i和B_i+对其进行重新计算来检查MAC标签σ。假设B_i为高熵，那么由于f为单向的，所以揭示s_i-1和s_i不泄漏B_i。

另一方面，如果s_i-1和s_i两者无法向

揭示(例如，当针对B_i的强行攻击可行时)，那么我们仍可通过使

修订含有块B_i的记录的前缀(或后缀)来减小成本。接着引发的成本为ZKP中的256-iSHA-2散列。本文中别处提供了额外细节。一般来说，ZKP成本与记录大小成比例，所以TLS分片操作也可通过恒定因数降低成本。

修订后缀.当要修订后缀B_i+时，

计算

且s_i为在B_i-‖B_i上应用f之后的状态。

将(π,B_i-‖B_i0发送到

验证器接着1)通过在B_i-‖B_i上应用f来检查s_i-1，和2)验证π。基本上，其安全遵循f的预成像抗性。此外，由于ih＝f(s,B_i+)向

保持秘密，所以

不学习修订后的后缀。总成本为ZKP中的3AES和256-iSHA-2散列。

修订前缀.

计算两个ZKPs:1)

将(π₁,π₂,s_i-1,B_i‖B_i+)发送到

验证器1)使用π₁检查s_i-1为正确的且接着计算f(s_i-1,B_i‖B_i+)以获得内部散列ih，2)使用计算出的ih验证π₂。引发的成本为ZKP中的3AES和256-i SHA-2散列。

应注意，修订前缀/后缀仅在所揭示部分不含任何私人用户数据的情况下有意义。否则，

将必须找到含有所有敏感块的最小子字符串且修订前缀/后缀，类似于上文。

GCM.不同于CBC-HMAC，揭示块在GCM中非常高效。首先，

揭示具有以ZK的正确性的证明的AES(k,IV)和AES(k,0)，以允许

验证密文的完整性。接着，为了揭示ith块，

仅揭示具有正确性证明的ith计数器C_i＝AES(k,incⁱ(IV))的加密。

可解密ith块，因为

为用于会话的公开初始向量，且incⁱ(IV)指代递增IV i次(inc的准确格式不重要)。为了揭示TLS记录，

针对每一块重复以上协议。同样，本文中别处提供了额外细节。

综上所述，CBC-HMAC允许在DECO中的块层级处的TLS记录层级和修订处的高效选择性揭示，而GCM允许在块层级处的高效揭示。选择性开放还可充当预处理以减少用于后续零知识证明的输入长度。

通过两阶段解析的上下文完整性.对于许多应用，验证器

可需要验证所揭示子字符串出现于正确上下文中。我们将这一性质称作“上下文完整性”。在下文中，我们呈现用于

以指定上下文的技术和用于

以高效证明上下文完整性的技术。

为了易于解释，我们的以下描述初始地聚焦于揭示模式，即，

揭示服务器对

的响应的子字符串。接着将描述修订模式。

上下文的规范.我们的用于指定上下文的技术假设发送到给定服务器

和从所述服务器发送的受TLS保护的数据具有对

和

两者已知的定义明确的上下文无关语法

在稍微滥用符号的情况下，我们假设

指代语法和其指定的语言两者。因此，

指代通过

给定的语言中的字符串R。我们假设

为明确的，即，每一

具有独特相关联解析树T_R。JSON和HTML为满足这些要求的两种广泛使用的语言的实例，且在这里是我们的焦点。

当

接着呈现来自

的一些响应R的子字符串R_开放时，我们说在以通过

预期的某一方式产生R_开放的情况下，R_开放具有上下文完整性。特定来说，

指定一组位置S，她可期望在所述位置中见到R中的有效子字符串R_开放。在我们的定义中，S为从由

定义的解析树中的根部到内部节点的一组路径。因此s∈S，我们称作可容许路径的是非末尾的序列。假设ρ_R指代T_R的根部(

中的R的解析树)。我们说如果T_R具有子树(其叶产生(也就是串接以形成)字符串R_开放)，那么字符串R_开放相对于(R，S)具有上下文完整性，且存在从ρ_R到所述树的根部的路径s∈S。

形式上，我们根据断言

定义上下文完整性。更特定来说，在给出TLS响应

上的语法

R的子字符串R_开放、一组可容许路径S的情况下，我们将上下文函数

定义为布尔型函数，使得当且仅当存在具有从

到

的路径s∈S的T_R的子树

且

产生R_开放时，

R_开放据称在

真的情况下相对于(R,S)具有上下文完整性。

再次参考图5的实例，根据所述实例考虑JSON字符串J。JSON含有(大致)以下规则：

开始→对象对象→{对}

对→“密钥”:值对→对|对,对

密钥→chars 值→chars|对象

在所述实例中，

对学习通过与密钥“检查a/c”配对ρ_检查的值给出的与对象中的密钥“余额”配对ρ_余额的导出感兴趣。这些非末尾中的每一个是用于解析树T_J中的节点的标记。从T_J的根部开始到ρ_检查的路径需要遍历形式开始→对象→对*→ρ_检查的节点的序列，其中对*指代零个或更多个对的序列。所以S为这种序列的组且R_开放为字符串“检查a/c”：{“余额”：$2000}。

两阶段解析.一般来说，在不直接揭示R的情况下证明R_开放具有上下文完整性，即，

这是由于计算

可需要针对潜在地较长的字符串R计算T_R。然而，我们观察到，在受TLS保护的数据通常满足的某些假设下，可通过使

通过应用由

和

协定的变换Trans而预处理R来去除许多开销，且证明R_开放相对于R′(通常短得多的字符串)和S′(由

基于S和Trans指定的一组可容许路径)具有上下文完整性。

基于这一观察，我们引入用于高效计算R_开放和证明

假设

和

协定

由网络服务器使用的语法，和变换Trans。假设

为用于所有

的字符串Trans(R)的语法。基于Trans，

指定可容许路径S′和约束条件检查功能

在第一阶段中，

(1)通过解析R来计算R的子字符串R_开放(使得

)(2)计算另一字符串R′＝Trans(R)。在第二阶段中，

以零知识向

证明(1)

和(2)

应注意，除公开参数

S、S′、Trans、

之外，验证器仅看见对R的提交，且最后，R_开放。

这一协议使得零知识计算通过推迟实际解析到不可验证的计算而显著地更便宜。换句话说，

和

的计算可比

的计算高效得多。

我们在下文给出的操作语义规则中形式化用于两阶段解析的正确性条件。这里，<f,σ>指代在输入σ上应用函数f，而

指代如果前提P为真，那么结论C为真。

在给定语法

上下文函数和可容许路径

变换Trans、具有上下文函数和可容许路径

和函数

的语法

的情况下，我们说如果对于所有(R,R′,R_开放)使得

布尔型b，那么

相对于S为正确的，以下规则成立：

下文，我们集中于适合用于DECO应用中的实例语法，且呈现两阶段解析方案的具体构造。

密钥值语法.广泛类别的数据格式，例如JSON，具有密钥值对的概念。因此，在DECO的一些实施例中其为我们的焦点。

密钥值语法

根据规则“对→开始密钥中间值结束”产生密钥值对，其中开始、中间和结束为定界符。对于这种语法，优化的阵列可极大地降低证明上下文的复杂度。我们在下文论述几个这种优化，其中本文中别处提供其它细节。

针对全局独特密钥的揭示.对于密钥值语法

路径组S，如果对于

符合上下文完整性的子字符串R_开放需要用全局独特密钥K将R_开放解析为密钥值对，那么R_开放仅需要为R的子字符串且正确地解析为一对。特定来说，Trans(R)输出含有所需密钥的R的子字符串R′，即，形式“开始K中间值结束”和

的子字符串可输出R_开放＝R′。

可由规则

其中

为用于

的产生规则中的开始符号。接着(1)

检查R′为R的子字符串且(2)对于

检查(a)

和(b)R_开放＝R′。在本文中的一些应用中产生全局独特密钥，例如当选择性开放对年龄的响应时。

密钥值语法中的修订.迄今为止，我们的两阶段解析的描述假设揭示模式，其中

向

揭示R的子字符串R_开放，且证明R_开放相对于由

指定的可容许路径组具有上下文完整性。在修订模式中，过程类似，但

使用先前描述的技术产生对R_开放的提交且在去除R_开放的情况下例如通过用虚设字符替换其位置而揭示R，而不是清楚地揭示R_开放。

应用

本文所公开的DECO可用于任何基于预言机的应用。为了说明其通用性，我们已实施且评估利用其各种能力的三个实例应用：1)由智能合约实现的机密金融工具；2)将传统凭证转换为匿名凭证；和3)隐私保护价格歧视报告。

机密金融工具.金融衍生物在最常列举的智能合约应用当中，且举例说明对认证数据馈送(例如，股票价格)的需要。举例来说，易于在智能合约中实施的一个流行的金融工具是二值期权。这是双方之间在指定未来时间(例如，第D天结束)关于一些资产N的价格P^*是否将等于或超出预定目标价格P(即，P^*≥P)而投注的合约。实施这一二值期权的智能合约可调用预言机

以确定结果。

原则上，对于链中的二值期权，

可隐藏基本资产N和目标价格P。其仅接受链下的期权细节，且仅报告指定结果Stmt:＝P^*≥？P的位。这一方法称作Mixicle。

基础Mixicle构造的局限性在于，

自身学习金融工具的细节。在DECO前，仅使用可信执行环境(TEE)的预言机服务可向

隐藏查询。我们现在展示DECO可如何在

不学习金融工具的细节(即，N或P)的情况下支持二值期权的执行。在这方面应注意，断言方向≥？或≤？可为随机化的。此外，可隐藏赢家和输家身份和支付量。可采取额外步骤来隐藏其它元数据，例如准确的结算时间。

在这一实例应用中，期权赢家发挥

的作用，且从发挥

的作用的

获得带符号结果Stmt。我们现在描述协议和其实施方案。

假设

指代预言机的密钥对。在这一实施例中，二值期权由资产名称N、阈值价格P和结算日期D指定。我们通过具有见证r_M的C_M＝com(M,r_M)指代消息M的提交。

图11说明执行机密二值期权的双方Alice和Bob。Alice使用DECO访问股票价格API且使

确信她已获胜。向右展示请求和响应的实例，且在图的这一部分中的加阴影文本为待修订的敏感信息。

图11中所说明的二值期权过程包含以下步骤：

1)设置：Alice和Bob协定二值期权{N,P,D}且创建具有识别符ID_SC的智能合约SC。合约含有

各方的地址和对具有两方已知的见证的期权{C_N,C_P,C_D}的提交。其还协定公开参数θ_P(例如，用以检索资产价格的URL)。

2)结算：假设Alice赢了交易。为了索取给付，她使用DECO来产生所检索的当前资产价格匹配她的位置的ZKP。Alice和

执行DECO协议(其中

充当验证器)以从θ_P(目标URL)检索资产价格。我们假设响应含有(N^*,P^*,D^*)。除DECO中的ZKP以证明起源θ_P外，Alice还证明以下陈述：

ZK-PoK{P,N^*,P^*,D^*,r_N,r_Pr_D：(P≤^*)∧

C_N＝com(N^*,r_N)∧C_P＝com(P,r_P)∧C_D＝com(D^*,r_D)}。

在成功证明验证后，预言机即刻与合约一起返回带符号陈述ID,

3)给付：Alice向合约提供带符号陈述S，其验证签名且向获胜方支付。

Alice和Bob需要信任

的完整性(但不是隐私)。如本文中别处所解释，其可进一步通过使用多个预言机相对于完整性失效而对冲。分散预言机上的信任为标准且已部署的技术。我们强调，即使所有预言机都为恶意的，DECO也确保隐私。

如上文所指示，图11展示股票价格API的请求和响应。用户

还需要向预言机

揭示HTTP GET请求的足够部分，以便确信对正确API端点的访问。GET请求含有若干参数，一些参数类似于API端点而揭示，且其它参数具有类似于股票名称和私人API密钥的敏感细节。

使用本文所公开的技术修订敏感param且向

揭示其余部分。API密钥提供防止

学习敏感param的足够熵。但在无额外关注的情况下，作弊的

可更改GET请求的语义且通过修订额外参数而隐藏作弊。为了确保这不发生，

需要证明定界符“&”和分隔符“＝”并不出现在修订后的文本中。

假设

和R分别指代响应密文和明文。为了结算期权，

使用先前描述的两阶段解析方案向

证明R含有他赢得期权的证据。在第一阶段中，

在本地解析R且识别可使

确信的R的最小子字符串。在涉及股票价格的图11实施例中，R_价格＝"05.price":"1157.7500"合格。在第二阶段中，

以ZK证明(R_价格,P,r_P)的知识，使得1)R_价格为

的解密的子字符串；2)R_价格开始于“05.price”；3)后续字符形成浮点数P^*且所述P^*≥P；和4)com(P,r_P)＝C_P。

假设密钥为独特的且密钥"05.price"后接价格，那么这一两阶段解析为安全的，使得这一响应的语法为具有独特密钥的密钥值语法，如上文所描述。类似地，

证明含于R中的股票名称和日期匹配提交。在CBC-HMAC密码程序组的情况下，零知识证明电路涉及修订整个记录(408字节)、计算提交和字符串处理。

HTTP GET请求(和HTML)具有特殊限制：密钥与值之间的分界(即，中间)和密钥值对的开始(即，开始)从不为密钥或值的子字符串。这意味着为了修订多于单个连续密钥或值，

必须修订{中间,开始}中的字符。所以我们使

检查：(1)|R|＝|R′|；和(2)

或R[i]＝R′[i](D为用于进行原位修订的虚设字符)。那么不必检查

传统凭证到匿名凭证：年龄证明.用户凭证通常在服务提供商的环境外部为不可访问的。一些提供商经由OAuth令牌提供第三方API访问，但这种令牌揭示用户识别符。DECO允许用户将凭证保存在现有系统中(我们称作“传统凭证”)以匿名地向第三方(验证器)证明关于其的陈述。因此，在一些实施例中，DECO允许用户在无服务器侧支持或可信硬件的情况下将任何基于网络的传统凭证转换成匿名凭证。

图12展示这一应用的实例，其中学生使用存储在大学网站上的凭证(人口统计详情)证明她的/他的年龄已满18岁。学生可向任何第三方提供年龄的这一证明，例如颁发驾驶员的证件的政府或寻求内科检验许可的医院。我们使用AES-GCM密码程序组和具有基于独特密钥的优化的两阶段解析实施这一实例。

在图12实例中，存储在大学网站上的学生的人口统计详情包含姓名、出生日期、学生ID等等。高亮显示的文本含有学生年龄。揭示模式与两阶段解析一起使用。证明器解析6到7个含有出生日期的AES块且以ZK向验证器证明她的年龄高于18岁。类似于其它实例，归因于包围出生日期的独特HTML标签，这也是具有独特密钥的密钥值语法。类似于二值期权应用，这一实例需要额外字符串处理以解析日期且计算年龄。

价格歧视.价格歧视是指以不同价格将相同产品或服务出售给不同买家。无处不在的消费者跟踪使得在线购物和预订网站能够采用复杂的价格歧视，例如，基于客户邮政编码调整价格。价格歧视可产生经济效率，且因此在现有法律下是广泛容许的。

然而，在美国，如果其导致竞争伤害，那么FTC禁止价格歧视，而欧洲新的以隐私为重点的法律(例如GDPR)重新把焦点放在了这种做法的合法性上。消费者在任何情况下通常都不愿意经受价格歧视。然而，当前，不存在供用户报告在线价格歧视的可信方式。

图13展示这一应用的实例，其中DECO允许买家通过证明商品的广告价格高于阈值来做出关于所察觉价格歧视的可验证声明，同时隐藏例如姓名和地址的敏感信息。我们使用用于TLS会话的AES-GCM密码程序组来实施这一实例，且揭示含有必要订单详情和请求URL的24个AES块。

如图13中所说明，在购物网站(例如Amazon)上的HTML中的订单发票页的部分包含个人详情，例如买家的姓名和地址。买家想要使第三方(验证器)确信关于特定日期的特定产品的收费价格。在这一实例中，我们使用AES-GCM密码程序组和揭示模式揭示订单发票页的上部部分中的必要文本，而下部部分中的加阴影敏感文本(包含加阴影买家姓名、地址和城市)是隐藏的。从响应揭示的AES块的数目为20(归因于较长产品名称)。另外，揭示来自请求的4个AES块以证明访问了正确端点。通过揭示周围的独特字符串来保证上下文完整性，例如，物品价格附近的字符串"<tr>Order Total∶"在整个响应中仅出现一次。

实施方案和评估

我们现在描述DECO和三种应用的实施细节和评估结果。

三方握手和查询执行.我们以约4700行C++代码实施用于TLS 1.2的三方握手协议(3P-HS)和查询执行协议(2PC-HMAC和2PC-GCM)。我们构建手动优化的TLS-PRF电路，其中总AND复杂度为779,213。我们还使用已知AES电路的变型。我们的实施方案针对Paillier密码系统使用Relic，针对恶意安全2PC协议使用EMP工具包。

我们将三方握手和2PC-HMAC协议与流行的TLS实施方案mbedTLS集成在一起，以构建端到端系统。2PC-GCM可以更多的工程努力类似地集成到TLS。我们单独地评估2PC-GCM的性能。集成的性能影响应该是可忽略的。我们未实施用于TLS 1.3的3P-HS，但认为性能应与用于TLS 1.2的性能相当，因为电路复杂度是类似的。

我们在LAN和WAN设定两者中评估DECO的性能。证明器和验证器两者在具有8vCPU核心和16GB RAM的c5.2xlarge AWS节点上运行。我们在LAN设定中将两个节点定位在相同区域(但不同的可用性区)中，但在WAN设定中定位在两个不同的数据中心(在俄亥俄州和俄勒冈州)中。LAN和WAN中的两个节点之间的往返时间分别为约1ms和67ms，且带宽为约1Gbps。

下表1汇总在TLS会话期间DECO协议的运行时间。使用50个样本计算平均值和平均值的标准误差(在括弧中)。我们使用的MPC协议依赖于离线预处理以改进性能。由于离线阶段是输入独立和目标独立的，所以其可在TLS会话前进行。仅在线阶段在关键路径上。

表1：3P-HS的运行时间和查询执行协议。所有时间以毫秒为单位。

如表1中所示，DECO协议在LAN设定中是非常高效的。其花费0.37秒来完成三方握手。对于查询执行，2PC-HMAC是高效的(每记录0.13s)，因为其在2PC中仅涉及一个SHA-2评估，而无关于记录大小。2PC-GCM通常更昂贵，且成本取决于查询长度，因为其涉及整个查询上的2PC-AES。我们以在256B到2KB范围内(见于HTTP GET请求中的典型大小)的查询评估其性能。在LAN设定中，性能为高效的且与2PC-HMAC相当。

在WAN设定中，运行时间由网络等待时间支配，因为MPC涉及许多回合的通信。然而，在DECO可能仅看到我们考虑的大多数应用的周期性使用的条件下，性能仍是可接受的。

证明产生.我们用libsnark中的标准证明系统对零知识证明进行例项化。我们已设计出可高效证明的陈述模板，但DECO的用户需要使其适应于其特定应用。SNARK编译程序实现高级语言中的这种调适，从而隐藏来自开发人员的低级详情。我们使用xjsnark和其Java类高级语言来构建陈述模板和libsnark兼容电路。

我们选择libsnark的基本依据为其相对成熟的工装支持。由libsnark所产生的证明为恒定大小且验证非常高效，不利方面为每电路可信设置。通过更多努力，DECO可适于使用例如Bulletproof，其不需要可信设置，但具有较大证明和验证时间。

我们针对每一实例测量五个性能度量——证明器时间(产生证明的时间)、验证器时间(验证证明的时间)、证明大小、电路中的算术约束条件的数目，和证明产生期间的峰值存储器占用率。

下表2汇总结果。使用50个样本来计算平均值和其标准误差。通过使用高效陈述模板和两阶段解析，DECO实现非常切实可行的证明器性能。由于libsnark针对低验证开销进行优化，所以验证器时间为可忽略的。归因于额外字符串解析例程，二值期权应用的约束条件(和证明器时间)的数目最高。我们在每一应用中使用多个证明来减少峰值存储器占用率。对于最复杂的应用，存储器占用率为1.78GB。由于libsnark证明为恒定大小287B，所以展示的证明大小为其倍数。

表2：在用于应用的DECO的证明产生阶段中产生和验证ZKP的成本。

端到端性能.DECO端到端性能取决于可用的TLS密码程序组、私人数据的大小和应用专用证明的复杂度。这里我们呈现我们实施的三个应用中的最复杂应用(二值期权)的端到端性能。花费约13.77s完成协议，其包含产生不可伪造提交(0.50s)、运行两阶段解析的第一阶段(0.30s)和产生零知识证明(12.97s)所花费的时间。在LAN设定中计算这些数字；在WAN设定中，MPC协议更费时(5.37s)，从而将端到端时间推到18.64s。

相比而言，Town Crier使用TEE在约0.6s内(即，比DECO快约20×)执行类似应用，但具有添加的信任假设。由于DECO可能仅周期性地用于大多数应用，因此其实现密码强度安全保证的开销似乎是合理的。

法律和遵守问题

尽管用户可能已从网站检索其数据，但DECO允许用户在没有他们的明确批准或甚至感知的情况下输出具有完整性证明的数据。我们现在简要地论述所产生的法律和遵守考虑因素。

然而，关键的是，DECO用户无法将具有完整性保证的数据单向导出到第三方，而是依赖于为此目的作为验证器的预言机。当DECO保持用户数据为私人的时，预言机学习用户访问的网站和数据类型。因此，预言机可强制执行适当的数据使用，例如，拒绝可导致版权侵犯的交易。

用户和预言机两者都对其访问的数据具有法律责任。然而，最近关于计算机欺诈和滥用法案(CFAA)的判例法展示出从网络抓取的犯罪化转变，且联邦法院已裁定违反网站的服务条款本身不是犯罪行为。违反网站服务条款(例如，“点击(click wrap)”条款)的用户和预言机变为冒着民事处罚的风险。DECO遵守给定站点的服务条款是站点和应用专用问题。

预言机具有在智能合约和其他生态系统内将其自身建立为可信任的动机。我们期望信誉良好的预言机将向用户提供其发布的特定证实和其准许的目标网站的菜单，审查这些选项以最大化安全性且最小化责任，且可能通知目标服务器或与目标服务器协作。

基于不正确(且可能受破坏)数据的不正确证实的法律、性能和遵守含义也是重要的。然而，当今的因特网服务具有复杂的多站点数据依赖性，因此这些问题并不是DECO特有的。预言机服务已依赖于多个数据源以帮助确保正确性。预言机服务通常最终可产生类似于证书的基础设施的基础设施，包含在线检查和撤销能力和不同的安全层次。

本文所公开的说明性实施例中的DECO是用于现代TLS版本的隐私保护、分散式预言机方案，其不需要可信硬件或服务器侧修改。DECO允许证明器产生对TLS会话的不可伪造的提交，且高效地证明关于会话内容的陈述。一些实施例利用新颖两阶段解析方案来减轻对隐私保护预言机普遍的上下文完整性攻击。DECO可从集中式网络服务仓释放数据，从而使其可由丰富的应用程序访问。DECO的实用性在本文中通过全功能实施方案连同三个实例应用一起展现。

GCM的协议详情

GCM为使用额外数据的认证加密(AEAD)密码。为了加密，GCM密码采用元组(k,IV,M,A):秘密密钥、初始向量、多个AES块的明文和待包含于完整性保护中的额外数据作为输入；其输出密文C和标签T。解密将过程反转。解密密码将(k,IV,C,A,T)用作输入，且首先通过比较重新计算的标签与T来检查密文的完整性，接着输出明文。

在计数器模式下计算密文：

其中incⁱ指代递增IV i次(inc的准确格式不重要)。

标签标签(k,IV,C,A)计算如下。在给定向量

的情况下，相关联GHASH多项式

用在

中进行的加法和乘法限定为

在不损失一般性的情况下，假设恰当地填充A和C。假设l_A和l_C指代其长度。GCM标签为

其中h＝AES(k,0)。

当在TLS中使用GCM时，如下加密每一明文记录D。选择独特临时值n，且将额外数据κ计算为D的序列号、版本和长度的串接。调用GCM加密以产生有效负载记录作为M＝n‖GCM(k,n,D,κ)。

关于GCM的额外细节可见于例如Morris J Dworkin，SP 800-38d，“用于块密码操作模式的推荐：Galois/计数器模式(GCM)和GMAC(Recommendation for block ciphermodes of operation:Galois/counter mode(GCM)and GMAC)”，技术报告(TechnicalReport)，2007，其以引用方式并入本文中。

查询执行

标签创建/验证.计算或验证GCM标签涉及评估2PC中的以上等式(1)。挑战为等式(1)涉及算术计算(例如，

中的多项式评估)以及二进制计算(例如，AES)两者。在二进制电路中的大域中进行乘法是昂贵的，而在

中计算AES(在GF(2⁸)中定义)引发高开销。即使计算可以某种方式分离到两个电路中，仅评估多项式(这针对每一记录在

中采用大约1,000个乘法)也将是过度昂贵的。

我们的协议去除对多项式评估的需要。实际2PC协议仅涉及二进制运算，且因此可在单个电路中完成。此外，每记录计算减少到2PC-AES的仅一个调用。

这通过在会话的开始处的预处理阶段中计算(2PC协议中的){hⁱ}的共享来实现。由于用于之后的所有记录的相同h，所以预处理的开销在会话上摊销(amortized)。使用{hⁱ}的共享，

和

可在本地计算多项式评估

的共享。其还计算2PC中的AES(k,IV)以获取Tag(k,IV,C,A)的共享。总的来说，仅需要2PC-AES的一个调用以检查每一记录的标签。

重要的是，

从不对同一IV作出响应多于一次；否则

将学习h。特定来说，在每一响应中，

揭示呈

形式的她的共享

的盲化线性组合。重要的是，值通过AES(k,IV)盲化，因为

的单个非盲线性组合将允许

针对h进行求解。因此，如果

对相同IV作出响应两次，那么可通过添加两个响应(在

中)来去除盲化：

这遵循GCM的临时值独特性要求。

加密/解密记录.一旦恰当地检查标签，记录的解密就是简单的。

和

简单地计算用2PC-AES对inc′(IV)的AES加密。应注意的细微之处是，

必须检查待加密的计数器先前尚未用作IV。否则，

将以类似于上文概述的方式将h学习到

证明产生

揭示块.

想要使

确信AES块B_i为加密记录

中的ith块。证明策略如下：1)证明AES块B_i加密到密文块

和2)证明标签正确。证明正确加密仅需要ZKP中的1个AES。不成熟地完成，证明正确标签引发评估阶次512的GHASH多项式和ZKP中的2个AES块加密。

我们能够通过允许

向

揭示两个加密消息AES(k,IV)和AES(k,0)来实现高效得多的证明，从而允许

验证标签(参见等式(1))。

仅需要证明ZK中的加密的正确性和使用的密钥对应于提交，从而需要2AES和1SHA-2(

通过揭示密钥的散列提交到

)。因此，在ZKP中总成本为3AES和1SHA-2。

揭示TLS记录.证明技术为从以上情况的简单扩展。

揭示整个记录rec且证明所有AES块的正确AES加密，从而产生ZKP中的总共514AES和1SHA-2。

揭示除块以外的TLS记录.类似于以上情况，

证明除一个块外的记录中的所有块的加密，从而产生ZKP中的总共513AES和1SHA-2。

协议扩展

调适以支持TLS 1.3.为了支持TLS 1.3，3P-HS协议必须适于新握手流程和不同密钥导出电路。值得注意的是，在ServerHello之后的所有握手消息现在都已加密。不成熟的策略将为在2PC中解密所述消息，这将是昂贵的，因为证书通常较大。然而，归功于TLS 1.3的密钥独立性性质，

和

可安全地揭示握手加密密钥而不影响最终会话密钥的秘密性。因为完成的消息使用又一独立密钥认证握手，因此保护了握手完整性。

因此，优化后的3P-HS如下起作用。

和

进行ECDHE，与之前相同。接着其通过执行2PC-HKDF来导出握手和应用密钥，且向

揭示握手密钥，从而允许

在本地(即，在无2PC的情况下)解密握手消息。2PC电路涉及SHA-256的大致30个调用，总计大约70k AND门，与用于TLS 1.2的调用相当。最后，由于CBC-HMAC不由TLS 1.3支持，所以DECO仅可在GCM模式下使用。

查询构造是任选的.对于将响应绑定到查询的应用，例如，当股票行情与引号一起包含时，可完全避免2PC查询构造协议。由于TLS针对通信的每一方向使用单独密钥，所以可在握手之后向

揭示客户端到服务器密钥，使得

可在不与

交互的情况下查询服务器。

支持多回合会话.DECO可扩展以支持多回合会话，其中

取决于先前响应而发送进一步查询。在每一回合之后，

如上执行类似2PC协议以验证传入响应的MAC标签，这是由于MAC验证和创建是对称的。然而，需要额外提交以防止

滥用MAC验证来伪造标签。

在TLS中，不同MAC密钥用于服务器到客户端和客户端到服务器通信。为了支持多回合会话，

和

运行2PC以验证用于前者的标签，且针对后者在新消息上创建标签。本文中的先前描述指定用以创建(和验证)MAC标签的协议。现在我们论述用于多回合会话的额外安全考虑因素。

当检查服务器到客户端消息的标签时，我们必须确保

无法伪造最初不是来自服务器的消息上的标签。假设

想要验证消息M上的标签T。我们使

首先提交到T，接着

和

运行2PC协议以计算消息M上的标签T′。要求

开放对

的提交且如果T≠T′，那么

中止协议。由于

不知道MAC密钥，所以

无法计算和提交到不是来自服务器的消息上的标签。

当创建用于客户端到服务器消息的标签时，

根据TLS的需要确保以增加序列号在消息上创建MAC标签。这还防止恶意

创建具有相同序列号的两个消息，因为不存在供

区分将哪一个发送到服务器的方式。

替代DECO协议：代理模式.如表1中所示，DECO的HMAC模式是高效的，且在2PC中创建和验证HMAC标签的运行时间独立于记录大小。GCM模式对于具有预处理的较小请求是高效的，但对于较大记录可能是昂贵的。我们现在呈现完全避免握手后2PC协议的高效替代方案。

在这一替代方案中，验证器

充当证明器

与TLS服务器

之间的代理，即，

通过

将消息发送到

/从其接收消息。DECO协议的修改后的流程如下：在三方握手之后，

提交到她的密钥共享

接着

向

揭示

因此，

现在具有整个会话密钥

由于

使用k继续与服务器的会话，所以

记录代理业务。在会话结束之后，

证明关于记录会话的陈述与之前相同。

在这种实施例中，三方握手提供不可伪造性。不同于CBC-HMAC，GCM不提交：给定密文和用密钥k加密的标签(C,T0，可发现在计算同一标签时将C解密为不同明文的k′≠k，因为GCM MAC不是抗冲突的。为了防止这种攻击，以上协议需要

在学习会话密钥之前提交到她的密钥共享。

现将描述与代理模式协议相关的安全性质和网络假设。验证器完整性和隐私性质是清晰的，因为恶意

无法打破TLS的完整性和隐私(通过假设)。

然而，针对证明器完整性，我们需要假设代理可在整个会话中可靠地连接到

首先，我们假设代理可确定其实际上与

连接。此外，我们假设在代理与

之间发送的消息无法由知道会话密钥且因此可修改会话内容的

篡改。

应注意，在三方握手期间，

可通过检查(标准TLS中的)新临时值上的服务器的签名来确证服务器的身份。然而，在握手之后，

必须依赖于网络层指示符，例如IP地址。在实践中，

因此必须具有正确、最新的DNS记录，且

与服务器之间的网络(例如，其ISP和骨干网络)必须恰当地确保抵抗流量注入，例如，通过边界网关协议(BGP)攻击的流量注入。在说明性实施例中，一般没有窃听问题。

这些假设已由类似代理设定中的其它系统涵盖，因为BGP攻击在实践中对于安装具有挑战性。我们可通过地理上分布验证器节点而进一步增强我们的协议来抵抗流量拦截。此外，各种已知检测技术可由验证器部署。通常在事实之后记录BGP攻击，因此，在适用时，可增强DECO的应用以支持撤销受影响会话(例如，当DECO用于在身份系统中发布凭证时)。

这一替代协议表示不同的性能-安全折衷。其为高效的，因为在握手之后未发生密集密码术，但其需要关于网络的额外假设且因此仅承受较弱网络对手。

密钥值语法和两阶段解析

准备和符号.我们将上下文无关语法(CFG)指代为

其中V为一组非末尾符号，Σ为一组末尾符号，P∶V→(V∪Σ)^*为一组产生或规则且S∈V为开始符号。我们使用‘-’指代一组减法且使用‘..’指代范围以标准符号定义用于CFG的产生规则。对于字符串w，解析器通过构造用于w的解析树来确定是否

解析树表示接着可用于提取语义的产生规则序列。

密钥值语法.这些为具有密钥值对的概念的语法。这些语法对于DECO尤其有趣，这是由于大多数API调用和响应实际上是密钥值语法。

如果存在语法

那么

据称为密钥值语法，使得在给定任何

的情况下，

和

可由以下规则定义：

S→对象

对象→无对字符串开放对一或多个对关闭

对→开始密钥中间值结束

对→对一或多个对|""

密钥→chars

值→chars|对象

chars→char chars|""

char→统一码-已转义|转义已转义|添加的Chars

特殊→开始特殊|中间特殊|结束特殊

开始→未转义_s开始特殊

中间→未转义_m中间特殊

结束→未转义_e结束特殊

转义→特殊|转义|...

在上文中，S为开始非末尾(表示

中的句子)非末尾开放和关闭对密钥值对组的开放和关闭进行区分，且开始、中间、结束为分别区分密钥值对的启动、密钥与值之间的分离和配对结束的特殊字符串。

为了去除解析特殊字符(即，在解析语法时具有特殊含义的字符)时的不明确性，使用特殊非末尾转义。举例来说，在JSON中，在前面是‘空格双引号’(“)且后面是双引号时对密钥进行解析。如果密钥或值表达式自身必须含有双引号，那么其前面必须是反斜杠(\)，即，转义。在以上规则中，在特殊字符之前的非末尾无转义意味着其可解析为特殊字符。因此，向前，我们可假设密钥值对的产生是明确的。因此，如果密钥值语法

中的字符串R的子字符串R′解析为一对，那么R′必须对应于R的解析树中的一对。

应注意，在以上密钥值语法中，中间无法导出空字符串，即，非空字符串必须标记中间以允许从值解析密钥。然而，开始和结束中的一个可具有空导出，这是由于其仅区分一对中的值与下一对中的密钥之间的分离。最后，我们应注意，在一些实施例中，在密钥值语法的两阶段解析中，我们仅考虑具有选择性开放的字符串R_开放对应于一对的要求的可容许路径。

用于本地独特密钥的两阶段解析.许多密钥值语法强制执行一范围内的密钥独特性。举例来说，在JSON中，可假设密钥在JSON对象内是独特的，即使跨对象可能存在复制的密钥。这种语法的两阶段解析可减少以解析子字符串。具体来说，Trans从R提取连续子字符串R′，使得即使在R′内也可正确地确定一对的范围。举例来说，在JSON中，如果

在且仅在R为R的前缀时返回真，那么仅将R解析为JSON，直到生成产生R_开放的子树足以确定字符串R_开放是否对应于R中的正确上下文为止。

具有独特密钥的语法.在给定密钥值语法

的情况下，我们定义检查密钥的独特性的函数，标示为

在给定字符串

和另一字符串k的情况下，当且仅当存在最多一个可解析为开始k中间的s的子字符串时，

由于

这意味着在s的任何解析树中，存在具有节点密钥和导出k的至多一个分支。假设

为在其输入在语法

中的情况下返回真的函数。如果对于所有

和所有可能密钥k,

那么我们说语法

为具有独特密钥的密钥值语法，即，对于所有字符串R,C：

用于独特密钥语法的具体两阶段解析.假设

为如上文所给出的独特密钥语法。我们假设

为LL(1)。这是例如先前所描述的所感兴趣语法的情况。通用LL(1)解析算法为已知的。

我们针对一组T对上下文函数

进行例项化，使得T含有到用于

中的字符串的配对的可容许路径。我们此外允许

采取辅助限制作为输入，所述辅助限制为密钥k(

的输出R_开放中的指定密钥)。元组(T,k)标示为S和

假设

为由规则

其中对为用于

的产生规则中的非末尾，且

为

中的开始符号。我们将

定义为函数，所述函数决定字符串s是否在

中，且如果是，s中的密钥是否等于k。在输入R、R_开放上，

(a)通过运行

检查R_开放为与密钥k的有效密钥值对(b)通过运行LL(1)解析算法以解析R来检查R_开放解析为R中的密钥值对。

图14展示用于函数

以在密钥值语法

中解析字符串R且搜索特定密钥值对R_开放的产生的实例伪代码。这里，将作为用于

的LL(1)解析表的PTable硬译码成

为了在长字符串R上对

的昂贵计算，我们引入变换Trans以提取R的子字符串R′，使得根据要求R′＝R_开放。

对于字符串s,t，我们还定义在t为s的子字符串的情况下返回真的函数子字符串(s,t)，和在s＝t的情况下返回真的相等(s,t)。我们用规则定义

和

意味着，每当相等(R′,R_开放)时

且规则

对所有字符串R′,S_开放都成立。

可展示，

相对于R是正确的。更特定来说，如果R′为R的子字符串，那么密钥值对R_开放由

解析，那么同一对一定为

的子字符串。归因于

中的密钥的全局独特性，仅存在一个这种配对R_开放且

必须为真。

上文的额外协议细节(类似于本文中别处所描述的那些)仅作为说明性实例呈现，且并不意图以任何方式为限制性的。其它实施例可利用替代协议布置来实施如本文所公开的分散式预言机。

如上文所指示，如本文所公开的分散型预言机的说明性实施例可在广泛多种不同应用中实施。

举例来说，DECO可用于实施个人数据市场，其中用户控制和出售其个人数据。众所周知，网页服务从货币化用户数据获益。使用本文所公开的技术实施的个人数据市场可通过使用户能够在开放市场中出售其数据而破坏这一数据。在说明性实施例中，DECO是个人数据市场的关键使能器，因为DECO使得买家能够验证来自网站的数据的来源和完整性。DECO还允许卖家预处理数据，例如修订敏感信息，用于隐私保护同时防止卖家作弊。一些实施方案利用DECO以提供针对价格歧视的可验证的声明。

作为另一实例，DECO可用于提供金融偿付能力的证明。作为这一类型的布置的更特定说明，使用DECO，Alice可向Bob证明她在特定银行的余额超过$5000。这一简单证明不仅显示了Alice的金融偿付能力，且还显示了她开立账户的能力(例如，在银行进行反洗钱(AML)筛查时，Alice不在任何制裁名单上)。重要的是，DECO通过仅揭示Alice的余额高于$5,000，而不是她的实际余额或身份来保护她的隐私。

作为另一实例，DECO可用于提供账户所有权的证明。在这种布置的一个说明中，使用DECO，可匿名地证明账户(例如电子邮件账户、社交媒体账户等)的所有权。举例来说，Alice可向Bob证明她拥有以@example.org结尾的电子邮件账户，而不揭示账户名称是什么。这证明了Alice与某个组织的联系，这对于例如举报、匿名投诉等是有用的。

如本文所公开的分散式预言机的应用的额外实例包含凭证恢复和分散式身份。作为前者的说明，DECO可使用户能够以避免使用OAUTH的隐私保护方式证明她可访问特定的网络资源，例如Facebook账户。这可使用户能够利用现有服务来证明她的身份以用于例如密钥恢复。作为后者的说明，DECO还可使用户能够以隐私保护方式证明她具有由第三方提供商确证的某些特征(例如，她已满18岁)。这是在本文中也称作匿名年龄证明的实例。这种证明可用于在分散式身份系统中构造凭证。

前述分散式预言机应用仅为实例，且不应以任何方式理解为限制性的。可在本文中别处发现关于如本文所公开的分散型预言机的这些和其它实例应用的实施方案的额外细节。

假设配置成实施如本文所公开的一或多个分散式预言机的信息处理系统的各种元件之间的通信经由一或多个网络进行。给定的这种网络可说明性地包含例如：全球计算机网络，例如因特网、WAN、LAN、卫星网络、电话或有线电视网络；蜂窝式网络，例如3G、4G或5G网络；使用例如蓝牙、WiFi或WiMAX的无线协议实施的无线网络，或这些和其它类型的通信网络的各种部分或组合。

实施如本文所公开的分散式预言机的功能性的至少一部分的给定处理装置可包含例如处理器、存储器和网络接口的组件。假设处理器以操作方式耦合到存储器且耦合到网络接口。存储器存储用于由处理器在实施处理装置的功能性的部分时执行的软件程序代码。

应理解，本文结合图1到14展示和描述的特定布置仅作为说明性实例呈现，且众多替代实施例是可能的。本文所公开的各种实施例因此不应理解为以任何方式限制。在其它实施例中，可利用用于实施分散式预言机的众多替代布置。举例来说，本领域的技术人员将认识到，可在其它实施例中使用替代处理操作和相关联的系统实体配置。因此可能的是，相对于说明性实施例的实体，其它实施例可包含额外或替代系统实体。此外，在其它实施例中，特定系统和装置配置和相关联的分散式预言机可变化。

还应注意，上文所描述的信息处理系统布置仅为示范性的，且可在其它实施例中使用替代系统布置。

如本文所描述的信息处理系统中的给定客户端、服务器、处理器或其它组件说明性地配置成利用包括耦合到存储器的处理器的对应处理装置。处理器执行存储于存储器中的软件程序代码以便控制处理操作和其它功能性的进行。处理装置还包括支持经由一或多个网络的通信的网络接口。

处理器以任何组合可包括例如微处理器、ASIC、FPGA、CPU、GPU、ALU、DSP或其它类似处理装置组件，以及处理电路系统的其它类型和布置。举例来说，由如本文所公开的给定处理装置提供的分散式预言机的功能性的至少一部分可使用这种电路系统实施。

存储器存储用于由处理器在实施处理装置的功能性的部分时执行的软件程序代码。存储这种程序代码以供对应处理器执行的给定这种存储器为本文中更通常称作具有体现于其中的程序代码的处理器可读存储媒体的内容的实例，且可以任何组合包括例如电子存储器，例如SRAM、DRAM，或其它类型的RAM、ROM、快闪存储器、磁性存储器、光学存储器或其它类型的存储装置。

另外，本发明的实施例可以集成电路的形式实施，所述集成电路包括处理电路系统，所述处理电路系统配置成实施与分散式预言机以及其它相关功能性相关联的处理操作。

给定实施例中的处理装置可以任何组合包含例如膝上型计算机、平板计算机或台式个人计算机、移动电话或其它类型的计算机或通信装置。举例来说，计算机或移动电话可用作用于实施与如本文所公开的分散式预言机相关联的功能性的至少部分的处理装置。包括与相应系统实体相关联的处理装置的信息处理系统的各种元件之间的这些和其它通信可经由一或多个网络进行。

如本文所公开的信息处理系统可使用一或多个处理平台或其部分来实施。

举例来说，可用于实施信息处理系统的至少一部分的处理平台的一个说明性实施例包括云基础设施，所述云基础设施包含使用在物理基础设施上运行的超管理器实施的虚拟机。这种虚拟机可包括经由一或多个网络彼此通信的相应处理装置。

在这种实施例中，云基础设施可进一步包括在超管理器的控制下在虚拟机中的相应者上运行的应用程序的一或多个集合。还可能使用多个超管理器，每一超管理器提供使用至少一个底层物理机器的一组虚拟机。在配置信息处理系统的各种组件的多个例项时，可利用由一或多个超管理器提供的不同组的虚拟机。

可用于实施如本文所公开的信息处理系统的至少一部分的处理平台的另一说明性实施例包括经由至少一个网络彼此通信的多个处理装置。假设处理平台的每一处理装置包括耦合到存储器的处理器。

同样，这些特定处理平台仅作为实例呈现，且信息处理系统可包含额外或替代处理平台，以及以任何组合的众多不同处理平台，其中每一这种平台包括一或多个计算机、服务器、存储装置或其它处理装置。

举例来说，用于实施本发明的实施例的其它处理平台可包括代替包括虚拟机的虚拟化基础设施或除包括虚拟机的虚拟化基础设施之外的不同类型的虚拟化基础设施。因此，在一些实施例中，有可能的是系统组件可至少部分地在云基础设施或其它类型的虚拟化基础设施中运行，包含利用Docker容器或使用基于Linux控制组或其它类似机制的操作系统级虚拟化实施的其它类型的Linux容器的虚拟化基础设施。

因此，应理解，在其它实施例中，可使用额外或替代元件的不同布置。这些元件的至少一个子集可共同地实施于共同处理平台上，或每一这种元件可实施于单独处理平台上。

此外，在信息处理系统中，计算机、服务器、存储装置或其它组件的众多其它布置是可能的。这种组件可经由任何类型的网络或其它通信媒体与信息处理系统的其它元件通信。

如先前所指示，如本文所公开的系统的组件可至少部分地以一或多个软件程序的形式实施，所述软件程序存储于存储器中且由处理装置的处理器执行。举例来说，与分散式预言机实体或系统的相关组件相关联的某些功能性可至少部分地以软件的形式实施。

本文中所描述的信息处理系统的特定配置仅为示范性的，且给定这种系统在其它实施例中可包含除特定展示的元件之外或代替特定展示的元件的其它元件，包含常见于这种系统的常规实施方案中的类型的一或多个元件。

举例来说，在一些实施例中，信息处理系统可配置成利用所公开技术在其它上下文中提供额外或替代功能性。

因此，在本文的一些实施例中在为TLS提供分散式预言机的上下文中说明的技术可以直接的方式调适以在其它上下文中使用。因此，本发明的说明性实施例不应视为受限于TLS或其相关联的处理上下文。

还应了解，本文中所描述的实施例中所使用的特定过程步骤仅是示范性的，且其它实施例可利用不同类型和布置的处理操作。举例来说，展示为在说明性实施例中连续地进行的某些过程步骤可在其它实施例中至少部分地彼此并行地进行。

应再次强调，如本文中所描述的本发明的实施例意图仅为说明性的。本发明的其它实施例可利用与本文中所描述的特定说明性实施例和在众多替代处理上下文中所利用的那些信息处理系统、网络和装置不同类型和布置的信息处理系统、网络和装置来实施。另外，本文中在描述某些实施例的上下文中作出的特定假设在其它实施例中不需要应用。本领域的技术人员将容易了解这些和众多其它替代实施例。

Claims

1.一种设备，其包括：

验证器装置，其包括耦合到存储器的处理器；

所述验证器装置配置成经由一或多个网络与客户端装置和服务器装置通信；

其中所述验证器装置进一步配置成：

参与与所述客户端装置和所述服务器装置的三方握手协议，其中所述验证器装置和所述客户端装置获得与所述服务器装置的安全会话的会话密钥的相应共享；

从所述客户端装置接收与所述服务器装置的所述安全会话相关的提交；

响应于接收到所述提交，向所述客户端装置释放与先前不可由所述客户端装置访问的所述安全会话相关的额外信息；和

至少部分地基于所述提交和所述额外信息验证作为所述安全会话的部分由所述客户端装置从所述服务器装置获得的数据的至少一个表征的正确性。

2.根据权利要求1所述的设备，其中所述验证器装置进一步配置成响应于由所述客户端装置从所述服务器装置获得的所述数据的所述至少一个表征的所述正确性的所述验证而起始一或多个自动化动作。

3.根据权利要求1所述的设备，其中所述验证器装置包括分散式预言机(oracle)系统的一组预言机节点中的特定预言机节点。

4.根据权利要求1所述的设备，其中所述验证器装置包括分布式验证器装置，其中所述验证器装置的功能性跨越多个相异处理装置分布。

5.根据权利要求1所述的设备，其中所述服务器装置包括具有传输层安全(TLS)函数的服务器装置且所述安全会话包括TLS会话。

6.根据权利要求1所述的设备，其中与所述安全会话相关的所述提交包括对作为所述安全会话的部分由所述客户端装置从所述服务器装置获得的查询响应数据的提交。

7.根据权利要求1所述的设备，其中与所述安全会话相关的所述提交包括对由所述客户端装置结合所述三方握手协议建立但先前不可由所述验证器装置访问的证明器密钥的提交。

8.根据权利要求1所述的设备，其中响应于接收到所述提交而释放到所述客户端装置的所述额外信息包括由所述验证器装置结合所述三方握手协议建立但先前不可由所述客户端装置访问的验证器密钥。

9.根据权利要求1所述的设备，其中所述验证器装置进一步配置成结合所述客户端装置与所述服务器装置之间的交互作为所述客户端装置的代理来操作，使得所述验证器装置经由作为所述代理来操作的所述验证器装置自动获得在所述客户端装置与所述服务器装置之间交换的密文作为所述安全会话的部分。

10.根据权利要求1所述的设备，其中所述验证器装置进一步配置成从所述客户端装置接收表征作为所述安全会话的部分由所述客户端装置从所述服务器装置获得的所述数据的一或多个陈述。

11.根据权利要求10所述的设备，其中所述一或多个陈述中的给定一个包括作为所述安全会话的部分由所述客户端装置从所述服务器装置获得的查询响应数据的选择性揭示的子字符串。

12.根据权利要求10所述的设备，其中所述一或多个陈述中的给定一个配置成通过利用多阶段解析协议来提供上下文完整性，在所述多阶段解析协议中，作为所述安全会话的部分由所述客户端装置从所述服务器装置获得的查询响应数据由所述客户端装置预处理以产生减少的数据，所述减少的数据随后由所述客户端装置结合待由所述客户端装置发送到所述验证器装置的所述给定陈述的产生来解析。

13.根据权利要求1所述的设备，其中结合所述三方握手协议，所述客户端装置和所述验证器装置与所述服务器装置共同地建立一或多个共享会话密钥，其中所述客户端装置具有所述一或多个共享会话密钥中的给定一个的第一共享，所述验证器装置具有所述给定共享会话密钥的第二共享，且所述服务器装置具有组合所述第一共享与所述第二共享的复合会话密钥。

14.根据权利要求1所述的设备，其中结合所述三方握手协议，所述客户端装置从所述服务器装置接收不可由所述验证器装置访问的加密密钥。

15.根据权利要求1所述的设备，其中所述验证器装置和所述客户端装置使用其与所述服务器装置的所述安全会话的所述会话密钥的相应共享来协作，以产生由所述客户端装置提供到所述服务器装置的查询，以请求所述服务器装置将所述数据发送到所述客户端装置。

16.根据权利要求15所述的设备，其中所述验证器装置和所述客户端装置使用其与所述服务器装置的所述安全会话的所述会话密钥的相应共享来协作，以验证由所述服务器装置响应于所述查询而提供到所述客户端装置的响应。

17.根据权利要求1所述的设备，其中结合所述三方握手协议，所述客户端装置和所述验证器装置建立相应证明器和验证器密钥。

18.根据权利要求17所述的设备，其中验证作为所述安全会话的部分由所述客户端装置从所述服务器装置获得的数据的至少一个表征的正确性包括验证由客户端装置提供到所述验证器装置的证明，其中所述证明由所述客户端装置至少部分地基于以下产生：(i)由所述客户端装置结合所述三方握手协议建立的所述证明器密钥；(ii)由所述验证器装置结合所述三方握手协议建立的所述验证器密钥；和(iii)所述客户端装置的秘密信息。

19.根据权利要求1所述的设备，其中验证作为所述安全会话的部分由所述客户端装置从所述服务器装置获得的数据的至少一个表征的正确性包括：

获得从所述安全会话的至少一个密文的至少一部分导出的数据；和

由所述客户端装置验证所述数据的至少一个表征的正确性。

20.一种由验证器装置进行的方法，所述验证器装置配置成通过一或多个网络与客户端装置和服务器装置通信，所述方法包括：

至少部分地基于所述提交和所述额外信息验证作为所述安全会话的部分由所述客户端装置从所述服务器装置获得的数据的至少一个表征的正确性；

其中进行所述方法的所述验证器装置包括耦合到存储器的处理器。

21.根据权利要求20所述的方法，其中验证作为所述安全会话的部分由所述客户端装置从所述服务器装置获得的数据的至少一个表征的正确性包括：

由所述客户端装置验证所述数据的至少一个表征的正确性。

22.根据权利要求20所述的方法，其中所述验证器装置进一步配置成结合所述客户端装置与所述服务器装置之间的交互作为所述客户端装置的代理来操作，使得所述验证器装置经由作为所述代理来操作的所述验证器装置自动获得在所述客户端装置与所述服务器装置之间交换的密文作为所述安全会话的部分。

23.一种包括非暂时性处理器可读存储媒体的计算机程序产品，所述非暂时性处理器可读存储媒体在其中存储有一或多个软件程序的程序代码，其中所述程序代码在由配置成经由一或多个网络与客户端装置和服务器装置通信的验证器装置执行时使得所述验证器装置进行以下操作，所述验证器装置包括耦合到存储器的处理器：

24.根据权利要求23所述的计算机程序产品，其中验证作为所述安全会话的部分由所述客户端装置从所述服务器装置获得的数据的至少一个表征的正确性包括：

由所述客户端装置验证所述数据的至少一个表征的正确性。

25.根据权利要求23所述的计算机程序产品，其中所述验证器装置进一步配置成结合所述客户端装置与所述服务器装置之间的交互作为所述客户端装置的代理来操作，使得所述验证器装置经由作为所述代理来操作的所述验证器装置自动获得在所述客户端装置与所述服务器装置之间交换的密文作为所述安全会话的部分。