Decentralized technique for verification of data in transport layer security and other contexts

Abstract

To provide decentralized techniques for verification of data in transport layer security, and the like.SOLUTION: An apparatus includes a verifier device comprising a processor coupled to a memory. The verifier device is configured to communicate over a network with a client device and a server device. The verifier device receives, from the client device, a commitment of a ciphertext relating to a secure session with the server device, and verifies correctness of characterization of data obtained by the client device from the server device as part of the secure session, based at least in part on the commitment. The verifier device operates as a proxy for the client device in conjunction with interactions between the client device and the server device, so that the verifier device automatically obtains the ciphertext exchanged between the client device and the server device as part of the secure session via the verifier device operating as the proxy.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 62 / 894,052, entitled “DECO: Decentralized Oracles for TLS,” filed Aug. 30, 2019, the entirety of which is incorporated herein by reference.

[0002] Statement of government support This invention was made with U.S. Government support under Grant Nos. CNS-1514163, CNS-1564102, CNS-1704615, and CNS-1933655 from the National Science Foundation (NSF), and Grant No. W911NF161-0145 from the Army Research Office (ARO). The U.S. Government has certain rights in this invention.

[0003] The field relates generally to information security, including techniques for, for example, verifying that data is from a particular source or otherwise verifying the accuracy of data obtained in the context of Transport Layer Security (TLS), as well as in other contexts. [Background technology]

[0004] Thanks to the widespread deployment of TLS, users can access private data over a channel with end-to-end confidentiality and integrity. What users cannot do, however, is prove to a third party the origin of such data, i.e., that it truly originates from a particular website. Existing approaches either introduce undesirable trust assumptions or require server-side modifications. As a result, the value of a user's private data is locked to its source. Summary of the Invention

[0005] The illustrative embodiments provide a decentralized oracle for TLS, and in many other applications where it is necessary or otherwise desirable to prove that data came from a particular source.

[0006] For example, some embodiments overcome the above-mentioned shortcomings of existing approaches by providing a decentralized oracle, illustratively referred to herein as DECO, that allows users to attest that portions of data accessed via TLS originate from a particular website, and, optionally, to prove statements about such data with zero-knowledge, keeping the data itself private. DECO can thus liberate data from centralized web service silos and make this data accessible to a broad range of applications. Advantageously, DECO in the illustrative embodiments functions without trusted hardware or server-side modifications.

[0007] In one embodiment, an apparatus includes a verifier device including a processor and a memory coupled to the processor. The verifier device is configured to communicate with a client device and a server device over one or more networks. The verifier device participates in a three-party handshake protocol with the client device and the server device, where the verifier device and the client device obtain respective shares of a session key for a secure session with the server device. The verifier device receives a commitment from the client device related to the secure session with the server device, and in response to receiving the commitment, reveals to the client device additional information related to the secure session that was not previously accessible to the client device. The verifier device verifies accuracy of at least one characterization of data obtained by the client device from the server device as part of the secure session based at least in part on the commitment and the additional information.

[0008] It should be understood that the above arrangements are merely examples and that many alternative configurations are possible.

[0009] These and other embodiments of the present invention include, but are not limited to, systems, methods, apparatus, processing devices, integrated circuits, and processor-readable storage media having software program code embodied therein. [Brief description of the drawings]

[0010] [Figure 1] 1 illustrates an information processing system that implements a decentralized oracle for TLS in an exemplary embodiment. [Diagram 2] FIG. 1 is a flow diagram of a process for implementing a decentralized oracle for TLS in an example embodiment. [Diagram 3] 1 illustrates an example of decentralized oracle functionality in an exemplary embodiment. [Figure 4] 1 illustrates multiple stages of device interaction in a decentralized oracle implementation comprising a server device, a prover device, and a verifier device in an exemplary embodiment. [Diagram 5] 1 illustrates example data including bank statement information used to demonstrate selective disclosure and context integrity attacks in an example embodiment. [Figure 6] FIG. 1 illustrates a detailed diagram of one possible implementation of a decentralized oracle protocol in an exemplary embodiment. [Figure 7] 1 illustrates a detailed example of a three-party handshake protocol utilized in implementing a decentralized oracle in an exemplary embodiment. [Figure 8] 4 illustrates a protocol executed between a prover device and a verifier device in establishing a key agreement in an exemplary embodiment. [Figure 9] 13 illustrates additional examples of protocols that may be utilized in conjunction with a decentralized oracle implementation in an exemplary embodiment. [Figure 10]13 illustrates additional examples of protocols that may be utilized in conjunction with a decentralized oracle implementation in an exemplary embodiment. [Figure 11] FIG. 1 illustrates an embodiment of a smart contract involving two parties, where one of the parties utilizes a decentralized oracle to obtain information that is provided to the smart contract. [Figure 12] 1 illustrates exemplary data processed using explicit and blackout modes for one or more respective decentralized oracles in an exemplary embodiment. [Figure 13] 1 illustrates exemplary data processed using explicit and blackout modes for one or more respective decentralized oracles in an exemplary embodiment. [Figure 14] 1 shows pseudocode for two-stage parsing of a unique key grammar in an exemplary embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Embodiments of the invention may be implemented in the form of an information processing system, including, for example, a computer network or other arrangement of networks, clients, servers, processing devices, and other components. Exemplary embodiments of such systems are described in detail herein. However, it should be understood that embodiments of the invention are more generally applicable to a wide variety of other types of information processing systems and associated networks, clients, servers, processing devices, or other components. Thus, the term "information processing system" as used herein is intended to be interpreted broadly to encompass these and other configurations.

[0012] 1 illustrates an information processing system 100 implementing a decentralized oracle for TLS in an exemplary embodiment. The system 100 comprises a plurality of client devices 102-1, 102-2, ... 102-N and a verifier device 104 configured to communicate over a network 105. A given one of the client devices 102 may comprise, for example, a laptop computer, a tablet computer or a desktop personal computer, a mobile phone, or another type of computer or processing device, as well as a combination of a plurality of such devices. The verifier device 104 may similarly comprise various types of processing devices, each including at least one processor and at least one memory coupled to the at least one processor.

[0013] Network 105 may illustratively include, for example, a global computer network such as the Internet, a wide area network (WAN), a local area network (LAN), a satellite network, a telephone or cable network, a cellular network such as a 3G, 4G, or 5G network, a wireless network implemented using a wireless protocol such as Bluetooth®, WiFi®, or WiMAX®, or various portions or combinations of these and other types of communication networks.

[0014] The system 100 further comprises a number of TLS servers 106 associated with respective protected data sources 108. The TLS servers 106 are illustratively configured to control access to the respective protected data sources 108 of these TLS servers. At least a subset of the protected data sources 108 illustratively includes respective HTTPS-enabled websites, HTTPS being a notation for Hypertext Transfer Protocol Secure, which is an extension of the Hypertext Transfer Protocol (HTTP). It should be appreciated that a wide variety of additional or alternative data sources may be used in other embodiments. The protected data sources 108 of the system 100 are protected in the sense that these data sources may be securely accessed via HTTPS through at least one of the TLS servers 106. Other data sources need not be accessible in this particular manner and may implement additional or alternative access control mechanisms and / or be publicly accessible using other types of secure protocols.

[0015] Also, it should be appreciated that while the exemplary embodiments herein utilize one or more servers of a particular type, such as TLS server 106, other types of secure protocols may be used in other embodiments and may be implemented in other types of server devices. Thus, the term "server device" as used herein is intended to be broadly interpreted and should not be considered in any way limited to a TLS server.

[0016] Client device 102 in some embodiments acts as a respective prover device with respect to verifier device 104 or other zero-knowledge proof (ZKP) oracle nodes 110 of system 100. Thus, verifier device 104 may be considered a ZKP oracle node of system 100. Thus, a given “verifier device,” as that term is used broadly herein, may include, for example, a particular oracle node of a set of oracle nodes of a decentralized oracle system such as system 100.

[0017] The particular number, types, and arrangement of devices and other components of system 100 are presented only as illustrative examples and may vary in other embodiments. For example, in this embodiment, only a single verifier device 104 is shown, but other embodiments may include multiple verifier devices, such as in an arrangement in which other ZKP oracle nodes 110 act as respective verifier devices. Also, one or more of TLS servers 106 may each be configured to control access to multiple of the protected data sources 108. Numerous other decentralized oracle arrangements are possible.

[0018] The verifier device 104 comprises a three-party handshake module 112, a post-handshake interaction module 114, and a proof verification module 116. These modules implement respective versions of the Decentralized Oracle Protocol, also referred to herein as the DECO Protocol, as described in more detail below.

[0019] The verifier device 104 of the present embodiment further comprises a processor 120, a memory 122, and a network interface 124. The processor 120 is operatively coupled to the memory 122 and to the network interface 124 via simplified exemplary interconnections shown in the figure.

[0020] Processor 120 may include, for example, a microprocessor, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a central processing unit (CPU), a graphic processing unit (GPU), an arithmetic logic unit (ALU), a digital signal processor (DSP), or other similar processing device components, as well as other types and arrangements of processing circuitry in any combination. At least a portion of the functionality of the decentralized oracle provided by a given processing device disclosed herein may be implemented using such circuitry.

[0021] The memory 122 stores software program code for execution by the processor 120 in implementing a portion of the functionality of the processing device. For example, at least a portion of the functionality of the modules 112, 114, and 116 may be implemented using program code stored in the memory 122.

[0022] Any such memory that stores such program code for execution by a corresponding processor is an example of what is referred to herein more generally as a processor-readable storage medium in which the program code is embodied, and may include, for example, electronic memory such as SRAM, DRAM, or other types of random access memory, read-only memory (ROM), flash memory, magnetic memory, optical memory, or other types of storage devices, in any combination.

[0023] An article of manufacture comprising such a processor-readable storage medium is considered an embodiment of the present invention. As used herein, the term "article of manufacture" shall be understood to exclude ephemeral propagating signals.

[0024] Other types of computer program products comprising a processor-readable storage medium may be implemented in other embodiments.

[0025] Additionally, embodiments of the present invention may be implemented in the form of an integrated circuit comprising processing circuitry configured to perform processing operations associated with one or more of the client device 102, the verifier device 104, the TLS server 106, and other ZKP oracle nodes 110.

[0026] Network interface 124 is configured to enable verifier device 104 to communicate with other system elements over network 105, and may comprise one or more conventional transceivers.

[0027] In operation, the verifier device 104 in the exemplary embodiment is configured to participate in a three-party handshake protocol with a given one of the client devices 102, such as client device 102-1, and a given one of the TLS servers 106. Such participation is illustratively controlled by a three-party handshake module 112 of the verifier device 104. In conjunction with the execution of the three-party handshake protocol, the verifier device 104 and the client device 102-1 obtain respective shares of a session key for a secure session with the given TLS server. The secure session illustratively includes a TLS session.

[0028] The verifier device 104 receives a commitment from the client device 102-1 related to a secure session with a given TLS server. In response to receiving the commitment, the verifier device 104 exposes to the client device 102-1 additional information related to the secure session that was not previously accessible to the client device 102-1. These operations related to the commitment are illustratively performed under the control of the post-handshake interaction module 114.

[0029] The verifier device 104 verifies the accuracy of at least one characterization of data obtained by the client device 102-1 from a given TLS server as part of the secure session based at least in part on the commitment and the additional information. Such verification is illustratively performed under control of the attestation verification module 116.

[0030] In some embodiments, the verifier device 104 is further configured to initiate one or more automated actions in response to verifying the accuracy of at least one characterization of data obtained by the client device 102-1 from a given TLS server. For example, the verifier device 104 may return verification information or other relevant information to the client device 102-1.

[0031] As an example, a commitment associated with a secure session may include a commitment to query response data obtained by client device 102-1 from a given TLS server as part of the secure session.

[0032] As another example, a commitment associated with a secure session may include a commitment to a prover key established by client device 102-1 in conjunction with a three-party handshake protocol, but not previously accessible to verifier device 104. Other types of commitments may be used in other embodiments.

[0033] In some embodiments, additional information released to client device 102-1 in response to receiving the commitment includes a verification key that was established by verifier device 104 in conjunction with the three-party handshake protocol, but was not previously accessible to client device 102-1.

[0034] In other embodiments, the verifier device 104 is further configured to act as a proxy for the client device 102-1 in conjunction with interactions between the client device 102-1 and a given TLS server, such that the verifier device 104 automatically obtains ciphertext exchanged between the client device 102-1 and a given TLS server as part of a secure session via the verifier device 104 acting as a proxy. Such an embodiment is referred to herein as a “proxy mode” arrangement.

[0035] The verifier device 104 in some embodiments is further configured to receive one or more statements from the client device 102-1 characterizing data obtained by the client device 102-1 from a given TLS server as part of the secure session.

[0036] For example, a given one of the one or more statements illustratively includes a selectively specified substring of query response data obtained by client device 102-1 from a given TLS server as part of a secure session.

[0037] As another example, a given one of the one or more statements is illustratively configured to provide context integrity through utilization of a multi-phase parsing protocol, where query response data obtained by client device 102-1 from a given TLS server as part of a secure session is pre-processed by client device 102-1 to generate reduced data that is subsequently parsed by client device 102-1 in conjunction with generating the given statement that is transmitted by client device 102-1 to verifier device 104.

[0038] A wide variety of other types of statements characterizing the data obtained by client device 102-1 from a given TLS server as part of a secure session may be used in other embodiments.

[0039] In some embodiments, in conjunction with a three-party handshake protocol, client device 102-1 and verifier device 104 jointly establish one or more shared session keys with a given TLS server, where client device 102-1 has a first share of a given one of the one or more shared session keys, verifier device 104 has a second share of the given shared session key, and the given TLS server has a composite session key that combines the first and second shares.

[0040] Additionally or alternatively, in conjunction with a three-party handshake protocol, client device 102-1 receives an encryption key from a given TLS server that is not accessible to verifier device 104.

[0041] In some embodiments, the verifier device 104 and the client device 102-1 cooperate using their respective shares of the session key of the secure session with a given TLS server to generate a query that is provided by the client device 102-1 to a given TLS server to request that the given TLS server send data to the client device 102-1.

[0042] The verifier device 104 and the client device 102-1 can similarly cooperate using their respective shares of the session key of the secure session with a given TLS server to respond to queries and to authenticate responses provided to the client device 102-1 by the given TLS server.

[0043] In some embodiments, in conjunction with the three-party handshake protocol, client device 102-1 and verifier device 104 establish respective prover and verifier keys. In such embodiments, verifying the accuracy of at least one characterization of data obtained by client device 102-1 from a given TLS server as part of the secure session illustratively includes verifying a proof provided by client device 102-1 to verifier device 104. The proof is illustratively generated by client device 102-1 based at least in part on (i) a prover key established by client device 102-1 in conjunction with the three-party handshake protocol, (ii) a verifier key established by verifier device 104 in conjunction with the three-party handshake protocol, and (iii) a secret of client device 102-1, such as a password or passcode.

[0044] In some embodiments, verifying the accuracy of at least one characterization of data obtained by the client device 102-1 from a given TLS server as part of a secure session illustratively includes obtaining data derived from at least a portion of at least one ciphertext of the secure session and verifying, by the client device 102-1, the accuracy of the at least one characterization of the data. The term "ciphertext," as used in this context and elsewhere herein, is intended to be broadly interpreted and is not to be deemed to require the use of any particular cryptographic protocol.

[0045] It should be recognized that the particular arrangements of components and other system elements shown in FIG. 1, and their associated processing operations described above, are presented only as illustrative examples, and that numerous alternative embodiments are possible.

[0046] For example, while verifier device 104 of system 100 is illustratively shown as a single processing device comprising a processor coupled to a memory, the verifier device in other embodiments may comprise a distributed verifier device in which the functionality of verifier device 104 is distributed across multiple individual processing devices. In such embodiments, the verifier role in the various protocols disclosed herein may be distributed across multiple individual parties executing a multi-party protocol, with each such party being associated with a different one of multiple processing devices of the distributed verifier device. Thus, the term "device" as used herein is intended to be interpreted broadly to encompass at least one processing device comprising a processor coupled to a memory, and thus multiple such processing devices, as in the case of a distributed verifier device.

[0047] 2 illustrates an exemplary process illustratively implemented at least in part by a verifier device 104 interacting with one of the client devices 102 as a prover with respect to data controlled by one of the TLS servers 106. It should be understood that this particular process is merely an example, and that additional or alternative processes may be performed, at least in part, by the prover, verifier, and server entities in other embodiments.

[0048] In this embodiment, the process illustratively includes steps 200-208. As noted above, at least a portion of these steps are performed at least in part by a verifier device 104 interacting with one of the client devices 102 and further involving one of the TLS servers 106. These components are also referred to as a verifier, a prover, and a server, respectively, in the context of the FIG. 2 process.

[0049] In step 200, the verifier participates in a three-way handshake protocol with a client and a server, with the client acting as the prover.

[0050] In step 202, in conjunction with a three-party handshake protocol, the verifier and the prover obtain their respective shares of a session key for a secure session with the server.

[0051] In step 204, the verifier receives from the prover a commitment associated with a secure session with the server.

[0052] In step 206, in response to receiving the commitment, the verifier discloses to the prover additional information related to the secure session that was not previously accessible to the prover.

[0053] In step 208, the verifier verifies the accuracy of at least one characterization of the data obtained by the prover from the server as part of the secure session based at least in part on the commitment and the additional information.

[0054] Many other techniques can be used in conjunction with a decentralized oracle implementation as disclosed herein.

[0055] Thus, the specific processing operations and other functionality described in conjunction with the flowchart of FIG. 2 are presented only as illustrative examples and are not to be construed as limiting the scope of the invention in any way. Alternative embodiments may use other types of processing operations involving verifier devices, prover devices, and server devices. For example, the order of process steps may be varied in other embodiments, or certain steps may be performed concurrently with one another rather than sequentially. Also, multiple instances of processes may be performed in parallel with one another within system 100 for different sets of respective provers, verifiers, and server devices. Thus, system 100 may implement multiple decentralized oracles simultaneously using the techniques disclosed herein.

[0056] Further aspects of the exemplary embodiments will now be described with reference to Figures 3-14.

[0057] Widespread deployment of TLS allows users to access private data over a channel with end-to-end confidentiality and integrity. However, what users cannot easily do under conventional practices is to prove to a third party the origin of such data, i.e., that it truly originates from a particular website. Existing approaches either introduce undesirable trust assumptions or require server-side modifications.

[0058] As a result, a user's private data is locked at its source: the user cannot export the user's data to other applications in an integrity-protected manner without assistance and permission from the current data owner.

[0059] Exemplary embodiments herein provide a technology called DECO (short for Decentralized Oracle) to address these and other problems. DECO allows users to attest that a piece of data accessed via TLS originates from a particular website, and optionally proves statements about such data with zero knowledge, keeping the data itself private. Advantageously, DECO in exemplary embodiments can be implemented without requiring trusted hardware or server-side modifications.

[0060] DECO can liberate data from centralized web service silos and make this data accessible to a wide range of applications. To demonstrate the power of DECO, we implement three applications that would be difficult to achieve without it: private financial products using smart contracts, conversion of legacy credentials to anonymous credentials, and verifiable claims against price discrimination.

[0061] It should be appreciated that these and other references to DECO herein refer to exemplary embodiments, and the specific features, functionality, advantages and other details of those embodiments are not to be construed as limiting in any way. Alternative embodiments may implement additional or alternative techniques for validating data sources in TLS and other contexts.

[0062] As noted above, TLS is a powerful and widely deployed protocol that allows users to access web data over a confidential, integrity-protected channel. However, TLS has serious limitations in that it cannot prove to a third party that the data accessed by a user truly originates from a particular website. As a result, the use of data is often limited to its origin, curtailing users' right to data portability, a right granted by recent regulations such as the GDPR.

[0063] Specifically, when users access data online via TLS, they cannot securely export the data without assistance (and therefore permission) from the current data owner. Thus, vast amounts of private data are intentionally or unintentionally locked away in the "deep web," the part of the web that is not publicly accessible.

[0064] To better appreciate this problem, consider the example of Alice wanting to prove to Bob that she is over 18 years of age. Currently, age verification services require users to upload an ID and detailed personal information, which creates privacy concerns. However, various websites, such as company payroll records or DMV websites, in principle store and provide verified dates of birth. Alice could send a screenshot of her date of birth from such a site, which is easily forged. Even if the screenshot were somehow proven to be genuine, it would leak information revealing not only that she is over 18 years of age, but also her exact date of birth.

[0065] Oracles, originally proposed to attest the provenance of online data to smart contracts, are a step toward exporting TLS-protected data to other systems with provenance and integrity guarantees. However, existing schemes have serious technical limitations. These existing schemes only work with deprecated TLS versions, do not provide privacy from the oracle (e.g., TLSNotary), or rely on trusted hardware (e.g., Town Crier), against which various attacks have recently emerged. Another class of oracle schemes assumes server-side cooperation, mandating that the server install TLS extensions or modify its application layer logic. Server-driven oracle schemes suffer from two fundamental problems. First, they break legacy compatibility, creating a significant barrier to wide adoption. Moreover, such solutions only offer conditional exportability, since the web server has the sole discretion to determine what data can be exported and can arbitrarily censor export attempts. A mechanism that allows users to export any data to which they have access would enable a whole host of applications that are currently not feasible.

[0066] To address the above problems, exemplary embodiments disclosed herein provide an arrangement called DECO, which is a decentralized oracle for TLS. Unlike oracle schemes that require per-website support, DECO is illustratively source-independent and supports any website that runs standard TLS. Unlike solutions that rely on website participation, DECO does not require server-side cooperation. Thus, a single instance of DECO may enable anyone to become an oracle for any website.

[0067] DECO makes abundant internet data accessible, with guaranteed authenticity and privacy, to a wide range of applications, including those that cannot access the internet, such as smart contracts. DECO could fundamentally shift today's web data dissemination model by providing private data delivery with options for transfer to a third party or public release. This technical capability highlights potential future legal and regulatory challenges, but at the same time, it also anticipates the creation and delivery of compelling new services. Importantly, DECO does not require trusted hardware, unlike some alternative approaches.

[0068] In some embodiments, at a high level, the prover commits a piece of data D and informs the verifier that D represents a TLS server S, and optionally a statement about D π D Returning to the age proof example, the statement π D could have the attribute "D=y / m / d is Alice's birth date, and the current date - D is at least 18 years old."

[0069] Informally, DECO achieves authenticity - i.e., the verifier is convinced that an asserted statement about D is true if and only if D was indeed obtained from a TLS server S. DECO also supports the notion that the verifier can assert a statement π D provides privacy in that the user only learns that the

[0070] Designing DECO with the required security and practical performance while using legacy TLS compatible primitives introduces several significant technical challenges. One challenge arises from the fact that TLS generates symmetric encryption and authentication keys that are shared by the client (e.g., DECO's prover) and the web server. Thus, a client can forge any TLS session data, in the sense that it signs the data with a valid authentication key.

[0071] To address this challenge, DECO introduces a novel three-party handshake protocol between a prover, a verifier, and a web server that makes an unforgeable commitment by the prover to the verifier on some TLS session data D. The verifier can verify that D authentically originates from the TLS server. From the prover's perspective, the three-party handshake preserves the security of TLS in the presence of malicious verifiers.

[0072] Efficient Selective Disclosure. After committing to D, the prover proves a statement about the commitment. While any statement can be theoretically supported, we optimize for what is likely to be the most common applications by revealing only a substring of the response to the verifier. We call such a statement selective disclosure. Fine-grained selective disclosure allows users to conceal sensitive information and reduces the input length to subsequent proofs.

[0073] While a naive solution would involve expensive verifiable decryption of TLS records using a comprehensive zero-knowledge proof (ZKP), the exemplary embodiments herein achieve order-of-magnitude efficiency improvements by exploiting the TLS record structure. For example, while a straightforward implementation of verifiable decryption of TLS records would involve zero-knowledge proof of correct circuit execution of 1024 AES calls, by leveraging the MAC-then-encrypt structure of CBC-HMAC, the exemplary embodiments herein can accomplish the same with only three AES calls.

[0074] Context Integrity. Selective disclosure allows a prover to reveal only a substring D' of a server's response D. However, the substring may mean different things depending on when it appears, and a malicious prover could cheat by quoting out of context. Thus, we need to prove not only that D' appears in D, but also that D' appears in the expected context, i.e., that D' has context completeness with respect to D (note that this is different from "context completeness" in privacy theory).

[0075] Context integrity attacks can be thwarted if the session content is structured and can be parsed. Fortunately, most web data adopts this format (e.g., JavaScript Object Notation (JSON) or Hypertext Markup Language (HTML)). A generic solution is to parse the entire session and prove that the declared parts belong to the required branch of the parse tree. However, under certain constraints that web data typically meets, parsing the entire session is not mandatory. Some embodiments disclosed herein provide a novel two-phase parsing scheme in which the prover preprocesses the session content and parses only the result, which is usually much smaller. From the definition of program equivalence as used in programming language theory, we draw to construct a formal framework for reasoning about the security of two-phase parsing schemes. Exemplary embodiments disclosed herein provide some practical realizations for specific grammars. The definition and construction generalize to other oracles. For example, a generic version of the content hiding attack may be prevented.

[0076] Regarding implementation and evaluation of the exemplary embodiments, DECO was designed and implemented as a complete end-to-end system. To demonstrate the power of the system, three applications were implemented: 1) confidentiality-preserving financial instruments using smart contracts, 2) conversion of legacy credentials to anonymous credentials, and 3) verifiable claims against price discrimination.

[0077] Experiments with these applications show that DECO is highly efficient. For example, for TLS 1.2 in a WAN setting, the online time to perform a three-party handshake is 2.85s, and for a 2PC query execution is 2.52s. Generating zero-knowledge proofs for the above mentioned applications takes approximately 3s to 13s. More detailed details are provided elsewhere in this specification.

[0078] DECO, as disclosed in conjunction with the exemplary embodiments described in detail below, advantageously provides a provably secure decentralized oracle scheme. DECO in some embodiments provides an oracle scheme for modern TLS versions that does not require trusted hardware or server-side modifications.

[0079] We also detail below a broad class of statements in TLS records that can be efficiently proven with zero-knowledge using DECO. Such statements allow a user to open only a substring of the session data commits. The optimization achieves significant efficiency improvements over a comprehensive ZKP.

[0080] Regarding context integrity attacks and mitigation, we identify a new class of context integrity attacks that are universal to privacy-preserving oracles and describe our mitigation approach involving a novel efficient two-stage parsing scheme.

[0081] Transport Layer Security (TLS) We now provide some background regarding the TLS handshake and record protocols on which DECO is built in the exemplary embodiment.

[0082] TLS is a family of protocols that provides privacy and data integrity between two communicating applications. Roughly speaking, the family consists of two protocols: the Handshake Protocol, which uses asymmetric cryptography to set up the session and establish shared client and server keys for the next protocol, the Record Protocol, where data is transmitted with confidentiality and integrity protection using symmetric cryptography.

[0083] Handshake. In the handshake protocol, the server and client first agree on a set of cryptographic algorithms (also known as a cipher suite). They then authenticate each other (client authentication is optional), and finally securely compute a shared secret that is used for the subsequent record protocol.

[0084] DECO in an exemplary embodiment utilizes Elliptic Curve Diffie-Hellman (DH) key exchange with ephemeral secrets (ECDHE), by way of example and not limitation.

[0085] Record Protocol. To transport application layer data (e.g., HTTP messages) over TLS, the Record Protocol first transfers the application data

number

number

[0086] Differences between TLS 1.2 and 1.3. Some embodiments herein focus on TLS 1.2, and later describe how to generalize the technology to TLS 1.3. Here, we briefly note the main differences between these two TLS versions: TLS 1.3 excludes support for legacy non-AEAD ciphers. Also, the handshake flow is reorganized. Now, all handshake messages after the ServerHello are encrypted. Finally, a different key derivation function is used. Additional details can be found in E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, 2018, which is incorporated herein by reference.

[0087] Multi-party computation Each has some secrets i Hold the party

number

number

[0088] There are two common approaches to 2PC protocols: Garbled circuit protocols encode f as a Boolean circuit, an approach best suited for bit operations (e.g., SHA-256). Other protocols leverage threshold secret sharing and are best suited for arithmetic operations. However, the functions computed in some embodiments using 2PC include both bit and arithmetic operations. We separate these functions into two components, using an optimized garbled circuit protocol for the bit operations and a secret sharing-based MtA protocol for the arithmetic operations. Additional details regarding an exemplary optimized garbled circuit protocol used in exemplary embodiments can be found in Xiao Wang, Samuel Ranellucci, and Jonathan Katz, “Authenticated Garbling and Efficient Maliciously Secure Two-Party Computation,” in ACM CCS, 2017, which is incorporated herein by reference. Additional details regarding the exemplary secret sharing-based MtA protocol used in the exemplary embodiments can be found in Rosario Gennaro and Steven Goldfeder, “Fast multiparty threshold ECDSA with fast trustless setup,” in ACM CCS, 2018, which is incorporated by reference herein. These are merely examples, and other types of protocols can be used in other embodiments.

[0089] We now describe the problem solved by an exemplary embodiment of DECO and present a high-level overview of its architecture.

[0090] Problem Statement: Decentralized Oracles Exemplary embodiments herein provide a protocol for building "oracles," entities that can attest to the origin and properties of online data. The goal is to allow a prover P to prove to a verifier V that a piece of data originates from a particular website S, and optionally to prove statements about such data with zero knowledge, while keeping the data itself secret. Accessing the data may require private input from P (e.g., a password), and such private information also needs to be kept secret from V.

[0091] In the exemplary embodiment, we focus on servers running TLS, a widely deployed security protocol suite on the Internet. However, TLS does not prove data origin by itself. TLS uses public key signatures for authentication, but symmetric key primitives to protect the integrity and confidentiality of exchanged messages, using a shared session key established at the beginning of each session. Therefore, P, who knows this symmetric key, cannot prove any statements about cryptographically authenticated TLS data to a third party.

[0092] The web server itself could take on the role of an oracle, for example by simply signing the data. However, server-driven oracles not only incur high adoption costs, but also put users at a disadvantage, and the web server could impose arbitrary constraints on the oracle's capabilities. Of interest would be a scheme that would allow anyone to attest to the origin of the data they have access to, without having to rely on a single central point of control such as the web server that provides the data.

[0093] In an exemplary embodiment, we address these and other challenges by introducing what we call a "decentralized oracle" that does not rely on cooperation from trusted hardware or web servers. This problem is much more advanced than previous oracles because it goes beyond those previous approaches by supporting proofs over arbitrary attributes of data, while eliminating solutions that require servers to modify the oracle's code, deploy new software, or use prediction markets.

[0094] Authenticated Data Feeds for Smart Contracts. An important application of the exemplary embodiments disclosed herein is in building authenticated data feeds (ADFs), i.e., data with verifiable provenance and accuracy, for smart contracts. Naturally, a wide variety of other applications are supported by the techniques disclosed herein.

[0095] In the context of ADF, smart contracts cannot participate in the 2PC protocol, so they must rely on oracle nodes participating as V on behalf of the oracle nodes. Thus, in some embodiments, DECO is deployed with a decentralized oracle network, where a set of independently operating oracles is available for use by smart contracts. Note that the oracles running DECO are trusted only for integrity, not for privacy. Smart contracts can further hedge against integrity flaws by querying multiple oracles and requiring, for example, majority agreement. We emphasize that privacy in DECO is maintained even if all oracles are compromised. Thus, DECO allows for the provision of ADFs derived from private data to smart contracts while keeping private data secret from the oracles.

[0096] Notation and Definitions In some embodiments, P is used to represent a prover, V is used to represent a verifier, and S is used to represent a TLS server.

number

number

[0097] As illustrated in Figure 3, the ideal functionality F Oracle We use F to model the essential properties of oracles. Oracle To isolate parallel executions of, we tag all messages with a unique session id, denoted as sid. Additional or alternative oracle properties may be used in other embodiments.

[0098] As shown in FIG. 3, in this embodiment, Oracle is the secret parameter θ from P s accepts a secret θ in P (e.g., a password), a query template Query, and a statement Stmt from V. The query template is s , and returns a complete query including the public parameters specified by V. An example query template is Query(θ s )“stock price of GOOG on Jan. 1st,2020 with API key=θ s ". The prover P can later prove that the query sent to the server is well-formed, i.e., constructed from a template, without revealing the secret. The statement Stmt is the function V wants to evaluate upon the server's response. Following the previous example, since the response R is a number, the following statement would compare it to a threshold: Stmt(R)="R>$1,000".

[0099] P checks the query template and the statement ("ok" and θ s After that, F Oracle F uses the constructed query from the template to retrieve a response R from S. Since we assume an honest server, R is the ground truth. Oracle sends Stmt(R) and the data source to V.

[0100] A decentralized oracle that does not require server-side modification or cooperation, i.e., S follows the unmodified TLS protocol, is of interest in this embodiment. More specifically, the decentralized oracle protocol for TLS, possibly together with an application layer protocol, is: 1) Prot is F Oracle 2) Prot S A three-party protocol, such as standard TLS.

number

[0101] Adversary Model and Security Properties. In an exemplary embodiment, consider a static, malicious network adversary, A. Compromised parties may arbitrarily deviate from the protocol, revealing the state of these parties to A. As a network adversary, A may be able to read, F, since TLS does not hide lengths. Oracle Learn the message length from P. Suppose P and V choose and agree on appropriate queries (e.g., this query should be idempotent for most applications) and statements according to the application layer protocol executed by S.

[0102] For a given query Q, we denote by S(Q) the server's honest response. We require that security persists if either P or V is compromised. Oracle reflects the following security guarantees:

[0103] Prover-Integrity: A malicious P cannot forge the origin of content, nor can it cause S to accept invalid queries or to erroneously respond to valid queries. Specifically, if a verifier inputs (Query, Stmt) and outputs (b, S), then P can prove Q=Query(θ s ) to S and must receive a response R = S(Q) such that b = Stmt(R).

[0104] Verifier-Integrity: A malicious V cannot cause P to receive a false response. Specifically, if P outputs (Q, R), then R must be the server's response to the query Q submitted by P, i.e., R = S(Q).

[0105] · Privacy: A malicious V only knows the public information (Query, S) and the evaluation of Stmt (R).

[0106] Substitution Protocol In the exemplary embodiment, we focus on two widely used representative TLS cipher suites: CBC-HMAC and AES-GCM. The technique generalizes to other ciphers as well (e.g., Chacha20-Poly1305, etc.). We first use CBC-HMAC to illustrate a specific embodiment, and later describe the technique for AES-GCM.

[0107] TLS uses separate keys for each direction of communication. Unless explicitly specified, we do not distinguish between the two and use k Enc and k MAC We use the notation '|' to represent the two-way session key.

[0108] In presenting an exemplary embodiment of DECO, we start with a swapping protocol and build step-by-step to the complete protocol.

[0109] F between (P,V) OracleThe replacement protocol that realizes the above is as follows: P queries a server S and records all messages sent to the server and received from the server as

number

number

number

number

[0110] Then, she performs zero-knowledge: 1) each

number

number

number

number

[0111] She also

number

number

number

[0112]

number

number

number

number

[0113] Unfortunately, this intuition is flawed. The swapping protocol

number

number

[0114] Moreover, the zero-knowledge proof that P needs to construct involves decrypting and hashing the entire transcript, which can be extremely expensive. For the protocol to be practical, the cost needs to be significantly reduced.

[0115] Overview of DECO A critical failure of the above substitution technique is that P learns the session key before P commits to the session. In an exemplary embodiment of DECO, the MAC key is withheld from P until P commits.

[0116] The TLS session between P and the server S must provide confidentiality and integrity. Furthermore, the protocol must not degrade performance below the requirements of TLS (e.g., trigger timeouts).

[0117] FIG. 4 illustrates an exemplary DECO implementation with a server device, a prover device, and a verifier device in an exemplary embodiment. DECO in this embodiment is implemented as a three-phase protocol. The first phase is a novel three-party handshake protocol in which a prover P, a verifier V, and a TLS server S establish a session key that is secretly shared between P and V. The handshake is a query execution phase in which P accesses the server according to the standard TLS protocol, but with the help of V. After P commits to the query and response, V reveals her key shares. Finally, P proves a statement about the response in the proof generation phase.

[0118] Three-party handshake. Essentially, P and V jointly act as TLS clients. P and V negotiate a shared session key with S in secret-shared form. We emphasize that this phase, like the rest of DECO, is completely transparent to S and does not require any server-side modifications.

[0119] For CBC-HMAC cipher suites, at the end of the three-party handshake, P and V are

number

number

number

[0120] A three-party handshake makes the aforementioned commitment of session data unforgeable as follows: At the end of the session, P first commits

number

number

[0121] Other cipher suites, such as GCM, can be supported as well, in which a single key is used for both encryption and MAC (for each direction). The handshake protocol similarly secretly shares the key between P and V. The handshake protocol for GCM is described in more detail elsewhere in this specification.

[0122] Query Execution. As mentioned, since the session key is secretly shared, P and V run an iterative protocol to construct a TLS message that encrypts the query. P then sends the message to S as a standard TLS client. For CBC-HMAC, P and V compute a MAC tag for the query, while GCM performs authenticated encryption. Note that the query is private to P and should not be leaked to V. Since the exhaustive 2PC case is expensive for large queries, we instead introduce a custom 2PC protocol, as described elsewhere herein, that is order-of-magnitude more efficient than the exhaustive solution.

[0123] As explained earlier, P must first obtain the session data before receiving V’s key shares.

number

[0124] Proof Generation. For unforgeable commitments, P is a commitment.

number

number

[0125] however,

number

number

[0126] Instead, DECO introduces two techniques to support efficient proofs for a broad general class of statements, what we call "selective disclosure" of TLS session transcripts. Selective disclosure involves either revealing a substring in V, or blacking out, i.e., removing a substring and hiding it from V.

[0127] FIG. 5 shows, as an illustrative example, a simplified JSON banking statement for user Bob acting as a prover. We use this example to demonstrate selective disclosure and context integrity attacks. Suppose Bob (P) wants to reveal his checking account balance to V. It would be undesirable to reveal the decryption key of his TLS session, in which case the entire statement including his transaction would also be revealed. Instead, using the techniques disclosed herein, Bob can efficiently reveal only the substring in lines 5-7. Alternatively, if he does not mind revealing his savings account balance, he may black out his transaction from line 7 onwards.

[0128] The two selective disclosure modes, revealing and blacking out substrings, are useful privacy-preserving mechanisms. These selective disclosure modes can also serve as preprocessing for subsequent zero-knowledge proofs. For example, Bob may want to prove that he has an account with a balance over $1000 without revealing the actual balance. In that case, he would prove with zero knowledge an attribute over the entire substring that contains his checking account balance ("Balance > $1000").

[0129] However, selective disclosure alone is insufficient for many applications because the context of a substring affects the meaning of this substring. Without what is called context integrity, P could cheat and reveal a substring that falsely appears to prove a claim to V. For example, Bob may not have a balance greater than $1000. But after seeing his bank statement, he may post a message to customer service in the same TLS session with the substring "balance":$5000, and then mirror his pending message (a form of reflection attack). He could then reveal this substring to fool V.

[0130] Various sanitization heuristics on the input to V supplied by the prover, such as truncating the session transcript, could potentially prevent some such attacks, but are vulnerable and susceptible to attack, just like other forms of web application input sanitization.

[0131] Instead, we introduce a rigorous technique for explicitly and privately parsing session data, which we call "zero-knowledge two-stage parsing." In this technique, P can obtain

number

[0132] FIG. 6 illustrates a more detailed example implementation of the DECO protocol introduced above. In this embodiment, the DECO protocol includes a three-party handshake phase, followed by a 2PC protocol for the query execution phase, and a proof generation phase. Each of these phases is described in more detail below. It should be appreciated that the specific details of this embodiment, as well as other embodiments disclosed herein, are presented by way of example only and should not be construed as limiting in any way. Those skilled in the art will recognize that additional or alternative techniques may be used.

[0133] Three-way handshake In some embodiments, the goal of the three-party handshake (3P-HS) is to secretly share a session key used in a TLS session with a server S between a prover P and a verifier V, completely transparent to the server S. We first focus on CBC-HMAC for illustration purposes and then adapt the protocol to support GCM.

[0134] FIG. 7 illustrates a formal specification of the three-party handshake protocol in an exemplary embodiment.

[0135] FIG. 8 illustrates an example ECtF protocol that is part of a three-party handshake protocol in some embodiments.

[0136] Again, the specific details of these protocols are merely examples and are not intended to be limiting in any way. For example, a wide variety of other types of three-party handshake protocols involving a prover, verifier, and server may be used in other embodiments. Thus, the term "three-party handshake protocol" as used herein is intended to be broadly interpreted.

[0137] Similar to a standard TLS handshake, 3P-HS involves two steps: First, P and V are secrets shared with the server through a TLS-compatible key exchange protocol.

number

[0138] Step 1: Key exchange.

number

[0139] The prover P generates periodic TLS handshake requests and a random nonce r c The handshake begins by sending the certificate, server nonce r to S (in a ClientHello message). s , and the signed ephemeral DH public key Y from S S =s S Upon receiving G (in Server-Hello and ServerKeyExchange messages), P checks the certificate and signature and forwards them to V. After performing the same checks, V also receives secret sV Sample and generate DH public key Y V =s V Send her part of G to P, who then sends another secret s P and the combined DH public key Y P =s P G+Y V to S.

[0140] Since the server S runs standard TLS, S stores the DH secret as Z=s S Y P· P (and V) owns its share of Z. P =s P Y S (and Z V =s V Y S ) is calculated as follows: Z=Z P +Z V and + is

number

[0141] Step 2: Key Derivation. Now that P and V have established their additive shares of Z (in the form of EC points), P and V go ahead and derive a session key by evaluating the TLS-PRF keyed on the x coordinate of Z.

[0142] The technical challenge here is to reduce the number of arithmetic operations (i.e.

number

[0143] Due to the prohibitive cost of adding EC points to a Boolean circuit, P and V use the ECtF protocol shown in Fig. 8.

number

number

number

[0144] Share conversion using ECtF. The ECtF protocol is

number

number

number

number

number

number

[0145] ECtF uses the multiplicative-additive (MtA) share transformation protocol as a building block. We use α,β:=MtA(α,b) to denote the execution of MtA between Alice and Bob with inputs α and b, respectively. At the end of the execution, Alice and Bob receive α and β such that a·b=α+β. This protocol can be generalized to handle vector inputs without increasing communication complexity. That is, the vector

number

number

number

[0146] We now describe the protocol for ECtF. ECtF has two main components. Let [α] denote the 2-out-of-2 sharing of α, i.e., [α] = (α1,α2), for i ∈ {1,2}, if party i has α i At the same time, α = α1 + α2. The first component is the share inversion: given [α], -1 This can be done as follows: Party i calculates a random value r i Then, we sample, execute MtA, and calculate δ1, δ2:=MtA((α1,r1),(r2,α2)). Note that δ1+δ2=α1·r2+α2·r1. Party i samples, v i = δ i +α i ·r1 is disclosed, so that both parties know v = v1 + v2. Finally, party i publishes β i =r i ·v -1 The protocol is β1+β2=α -1 Therefore, α -1 Moreover, assuming that MtA is secure, the protocol does not leak α to any party. Indeed, party i’s view consists of (α1+α2)(r1+r1), where r i This is uniformly random since is uniformly random.

[0147] The second component is share multiplication: given [α] and [b], compute [αb]. [αb] can be computed using MtA as follows: Party i runs MtA to compute α1, α2, such that α1+α2=α1·b2+α2·b2. Party i then multiplies m i = α i +α i y i The security and correctness of the protocol can be discussed similarly to above.

[0148] Secure Evaluation of TLS-PRF. Having calculated the x-coordinate shares of Z, the so-called pre-master secret of TLS in ECtF, P and V evaluate the TLS-PRF in 2PC to derive the session key. Using the known SHA-256 circuit, we manually optimize the TLS handshake circuit, resulting in a total complexity of 779,213 AND circuits.

[0149] Adaptation to support GCM. In GCM, a single key is used for both encryption and MAC (for each direction). Adapting the above protocol to support GCM in TLS1.2 is straightforward. Since GCM keys are shorter, the output of the second step needs to be truncated, while the first step will remain the same.

[0150] Adaptation to TLS1.3. To support TLS1.3, the 3P-HS protocol must be adapted to a new handshake flow and a different key derivation circuit. In particular, now all handshake messages after the ServerHello are encrypted. A naive strategy would decrypt them in 2PC, which would be costly since the certificates are usually large. However, thanks to the key independence property of TLS1.3, it is possible to build a 3P-HS protocol with similar complexity as for TLS1.2, as described elsewhere in this document.

[0151] Query execution After the handshake, the prover P sends her query Q to the server S as a standard TLS client, but with the help of the verifier V. Specifically, since the session key is secretly shared, the two parties need to interact and run the 2PC protocol to construct a TLS record that encrypts Q. Although a comprehensive 2PC would be sufficient in theory, it would be expensive for large queries. Instead, we introduce a custom 2PC protocol that is more efficient order-of-magnitude.

[0152] We first focus on one-round sessions, where P sends all queries to S before receiving any responses. Most applications of DECO, e.g., proving the origin of content retrieved via HTTP GET, are one-round. Extending DECO to support multi-round sessions is described elsewhere in this document.

[0153] CBC-HMAC. Recall that P holds an encryption key, while P and V hold shares of the MAC key. To construct a TLS record that encrypts a potentially private Q to P, the two parties first run the 2PC protocol to compute an HMAC tag τ for Q, then P encrypts Q||τ locally and sends the ciphertext to S.

[0154] Let H denote SHA-256. Recall that the HMAC of message m with key k is:

number

[0155] The terms ipad and opad represent the respective "inner" and "outer" values ​​utilized in the HMAC algorithm. A straightforward 2PC implementation would be expensive for large queries, since 2PC requires hashing the entire query to compute the inner hash. This is advantageously avoided in the exemplary embodiment by computing the inner hash local to P (i.e., without 2PC). If P is

number

number

[0156] This optimization exploits the Merkle-Damgard construction of SHA-256. Assume that m1 and m2 are two blocks of the correct size. Then,

number

number

[0157] Figure 9 shows the post-handshake protocol for CBC-HMAC.

[0158] After the three-way handshake, P and V execute a simple 2PC protocol to

number

[0159] AES-GCM. For GCM, P and V perform authenticated encryption of Q. 2PC-AES is straightforward with optimized circuits, but computing tags for large queries is expensive since it involves evaluating a long polynomial in a large field for each record. The optimized protocol pre-computes local polynomial evaluations, as described in more detail elsewhere in this document. Because 2PC-GCM involves not only tag creation but also AES encryption, it incurs higher computational cost and latency than CBC-HMAC.

[0160] Other embodiments disclosed herein utilize a highly efficient alternative protocol, called the Proxy Mode Protocol, which has additional trust assumptions and avoids the Post-Handshake 2PC Protocol entirely.

[0161] As illustrated in the full DECO protocol shown in Figure 6, after querying the server and receiving the response, P commits to the session by sending a ciphertext to V and receives V's MAC key share. P can then verify the integrity of the response and prove statements about it. Figure 6 specifies the full DECO protocol for CBC-HMAC. The DECO protocol for GCM is similar and is described elsewhere herein.

[0162] For clarity, we present the details of a zero-knowledge proof as an ideal functionality F ZK We abstract the above as follows. When x and w are received from P, which is a private witness and a public witness, respectively, ("prove", x, w), F ZK sends w and the relation π(x,w)∈{0,1} (defined below) to V. Specifically, for CBC-HMAC, x, w, and π are defined as follows:

number

number

number

number

[0163] Given the functionality of secure 2PC and ZKP, the Prot DECO For a malicious adversary, F in Figure 3 Oracle We can demonstrate that this can be achieved in a UC secure manner.

[0164] More specifically, the groups used in the three-party handshake have a hard individual log problem, and if f (the compression function for SHA-256) is a random oracle, then Prot DECO against a static malicious adversary with abort, (F 2PC , F ZK ) Hybrid World F Oracle This is made possible through UC Secure.

[0165] The GCM protocol has a similar flow. The GCM variant of the three-party handshake and query construction protocol was described above.

[0166] Figure 10 shows the 2PC protocol for verifying tags and decrypting records in the GCM variant, also known as the GCM post-handshake protocol.

[0167] Unlike CBC-HMAC, GCM is non-committal: for a given ciphertext C encrypted with key k, someone who knows k can efficiently find k' ≠ k that decrypts C to a different plaintext while still passing an integrity check. To prevent such attacks, P must know her key share k before learning V's key shares. P In the proof generation phase, in addition to proving statements about Q and R, P must also commit to

number

number

[0168] Proof Generation A prover P verifies the ciphertext of the TLS session.

number

number

number

number

[0169]

number

number

[0170] In the following discussion, we present two classes of statements optimized for example applications: revealing only a substring of a response while proving its origin ("selective disclosure"), or additionally proving that the revealed substring appears in a context expected by V ("context completeness via two-stage parsing").

[0171] Selective Disclosure. Exemplary embodiments implement a technique referred to herein as “selective disclosure” that allows P to efficiently reveal or black out substrings in the plaintext.

number

number

number

number

number

[0172] CBC-HMAC. To generate the proof, P is given a cryptographic key k Enc and the MAC key k MAC V holds both the MAC key k MAC Recall that only the plaintext record is kept. The performance assumes a cipher suite with SHA-256 and AES-128, which is consistent with the implementation, but these techniques are applicable to other parameters. Recall that a MAC followed by encryption is used:

number

number

number

number

number

number

number

[0173] TLS record specification.

number

number

[0174] By leveraging the MAC-then-encrypt structure, we can achieve the same result using only three invocations of AES in our ZKP.

number

number

number

number

number

[0175] Specifying Records with Redacted Blocks. Suppose the i-th block contains sensitive information that P wants to redact. A straightforward strategy is

number

number

number

number

[0176] This is expensive as it involves 3x AES and 256x SHA-256 compression in the ZKP.

[0177] Taking advantage of the Merkle-Damgard structure of SHA-256, several optimizations are possible. Let f denote the compression function of SHA-256, and s i-1 in,

number

number

number

number

number

[0178] On the other hand, s i-1 ands i When it is not possible to specify both B and V (e.g., B i (if a brute force attack against is feasible), Block B i The cost can still be reduced by having P blackout the prefix (or suffix) of records containing . The cost then incurred is 256-i SHA-2 hashes on the ZKP. Additional details are provided elsewhere in this document. In general, ZKP costs are proportional to the record size, so TLS fragmentation can also reduce the cost by a constant factor.

[0179] Blacked out suffix. Suffix

number

number

number

number

number

number

[0180] Blacking out the prefix. P computes two ZKPs:1)

number

number

number

[0181] Note that blacking out prefixes / suffixes only makes sense if the designated parts do not contain private user data, otherwise P would need to find the smallest substring that contains all sensitive blocks and black out any prefixes / suffixes as above.

[0182] GCM. Unlike CBC-HMAC, revealing blocks is very efficient in GCM. First, P reveals AES(k,IV) and AES(k,0) with correctness proofs in ZK, allowing V to verify the integrity of the ciphertext. Then, to reveal the i-th block, P reveals the i-th counter C with correctness proofs. i =AES(k,inc i We only need to specify the encryption of the i-th block.

number

[0183] In summary, CBC-HMAC allows for efficient selective disclosure at the TLS record level and blacking at the block level for DECO, while GCM allows for efficient disclosure at the block level. Selective disclosure can also act as a preprocessing step to reduce the input length for the subsequent zero-knowledge proof.

[0184] Context Completeness with Two-Stage Parsing. For many applications, a verifier V may need to verify that an explicit substring appears in the correct context. We call this property "context completeness". Below we present techniques for V to specify a context, and a trick for P to efficiently prove context completeness.

[0185] For ease of explanation, the following discussion first focuses on the explicit mode, i.e., P makes a substring of the server's response to V explicit. Then, the blackout mode is described.

[0186] Context Specification. Our technique for specifying a context assumes that TLS-protected data sent to and from a given server S has a well-defined, context-free grammar G known to both P and V. With a slight abuse of notation, let G denote both the grammar and the language it specifies. Thus, R∈G denotes a string R in this language given by G. G is unambiguous, i.e., every R∈G has a unique associated parse tree T R JSON and HTML are examples of two widely used languages ​​that meet these requirements and are our focus here.

[0187] Then P is a substring R of some response R from S. open If you present R open If is generated in a particular way expected by V, then R open We say that V has context completeness. Specifically, V is a substring of R that is valid in R. open We specify a set S of locations where we can expect to see G. In this definition, S is the set of paths from the root of the parse tree defined by G to the internal nodes. Thus, a sequence of s∈S, called an admissible path, is a non-terminal sequence. ρ R So, T R represents the root of the parse tree of R in G. R But the leaves are string R open If a string R open is context complete with respect to (R,S), and ρ R We say that there exists a path s∈S from s to the root of the subtree.

[0188] Formally, the attribute CTX G More specifically, we define context completeness in terms of a substring R of a grammar G, R∈G,R at the time of the TLS response. open ,Given a set S of allowable paths,

number

number

number

number

number

number

[0189] Referring back to the example in Figure 5, consider a JSON string J according to that example. JSON includes (roughly) the following rules: [Table 1]

[0190] In that example, V is a pair ρ with key “checking a / c”. checking Pair ρ with key "balance" in the object given by the value of balance Each of these non-terminals is a derivation of the parse tree T J are the labels of the nodes in T J From the start of the root of checking The route to the start is: Start → Object → Pairs * →ρ checkingWe need to traverse a sequence of nodes of the form * denotes a sequence of zero or more pairs, so that S is the set of such sequences and R open is the string "checking a / c" {"balance":$2000}.

[0191] Two-step parsing. In general, you can use R without specifying R directly. open has context completeness, i.e.

number

[0192] Based on this observation, R open Efficiently compute

number

number

number

number

[0193] This protocol makes zero-knowledge computations significantly less expensive by deferring the actual parsing to non-verifiable computations.

number

number

number

[0194] We formalize the correctness conditions of two-phase parsing in terms of the operational semantics rules given below, where (f,σ) denotes the application of function f to input σ, while

number

[0195] Grammar G, context function and allowable paths CTX G(S,·,·), a transformation Trans, a grammar G'={R':R'=Trans(R),R'∈G}, a context function and an admissible path CTX G’ (S', , ), and the function cons G,G’ Given R′∈G, for all (R,R′,R open ), if a boolean b holds the following rules: (cons G,G’ , S') is said to be true with respect to S.

number

[0196] Key-Value Grammars. A broad class of data formats, such as JSON, have the notion of key-value pairs. They are therefore the focus of some embodiments of DECO.

[0197] A key-value grammar G generates key-value pairs according to the rule "pair → start key intermediate value end", where start, middle, and end are delimiters. For such grammars, an array of optimizations can significantly reduce the complexity for proving contexts. Such optimizations are discussed below, with additional details provided elsewhere in this specification.

[0198] An explicit representation for globally unique keys. For a key-value grammar G, a set of paths S is a set of substrings R ∈ G that satisfy context completeness. open But R open needs to be parsed as a key-value pair with a globally unique key K, then R open is simply a substring of R and must be parsed correctly as a pair. Specifically, Trans(R) outputs a substring R' of R that contains the desired key, i.e., a substring of the form "start K intermediate end", and P is a substring of R open =R' can be output. G' can be output as S G’If is the start symbol in a production rule of G', then rule S G’ →It can be defined by pairs. Then, (1) cons G,G’ (R,R') checks whether R' is a substring of R, and (2) S' = {S G’}About CTX G '(S',R',R open ) if (a) R'∈G' and (b) R open = R'. Globally unique keys arise in some applications herein, such as in the selective disclosure of responses to age.

[0199] Blacking in key-value grammars. Thus, so far, this description of two-phase parsing has been limited to the case where P is a substring R of R. open is specified for V, and R open Assume the explicit mode, which proves that V is context complete with respect to the set of admissible paths specified by V. In the blackout mode, the process is similar, but open Instead of making it clear, P can use the techniques described above to make R open Generate a commitment for R, for example by replacing its position with a dummy character. open Remove and make R explicit.

[0200] application DECO as disclosed herein can be used for any oracle-based application. To illustrate the versatility of DECO, three exemplary applications leveraging its various capabilities have been implemented and evaluated: 1) Confidential Financial Instruments enabled by Smart Contracts, 2) Conversion of Legacy Credentials to Anonymous Credentials, and 3) Privacy-Preserving Price Discrimination Reporting.

[0201] Confidential financial instruments. Financial derivatives are one of the most commonly cited smart contract applications and exemplify the need for authenticated data feeds (e.g., stock prices). For example, a popular financial instrument that is easy to implement with a smart contract is the binary option, which determines the price P of some asset N at a specified future time, e.g., the end of day D. * is equal to or exceeds a given target price P, i.e., P * It is a contract between two parties to bet on whether P ≥ P. A smart contract implementing this binary option can call an oracle O to determine the outcome.

[0202] In principle, O could hide the underlying asset N and target price P of a binary option on-chain. O simply accepts the details of the option off-chain and writes the result Stmt:=P * It reports only the bits that specify ≧?P. This method is called Mixicle.

[0203] A limitation of the basic Mixicle construction is that O itself knows the details of the financial instrument. Before DECO, only an oracle service using a trusted execution environment (TEE) could hide queries from O. Here, we show how DECO can support the execution of binary options without knowing the details of the financial instrument, i.e., N or P. In this regard, note that the attribute direction ≧? or ≦? can be randomized. Also, the identities of winners and losers and the payout amounts can be hidden. Additional steps can be taken to hide other metadata, e.g., the exact settlement time.

[0204] In this example application, the winner of the option plays the role of P and obtains the signed result of Stmt from O, which plays the role of V. We now describe the protocol and its implementation.

[0205] {sk O ,pkO} represents the oracle's key pair. In this embodiment, a binary option is specified by an asset name N, a threshold price P, and a settlement date D. M C with M =com(M,r M ) represents the commitment of message M.

[0206] Figure 11 illustrates two parties, Alice and Bob, playing confidential binary options. Alice uses DECO to access a stock quote API to convince O that she has won. An example request and response is shown on the right, and the shaded text in this part of the diagram is confidential information that should be blacked out.

[0207] The binary options process illustrated in FIG. 11 includes the following steps: 1) Setup: Alice and Bob agree on a set of binary options {N,P,D} with an identifier ID SC Create a smart contract SC with the address of the parties and a proof known to both parties, option {C N ,C P ,C D}. They also include a public parameter θ P (e.g. a URL to retrieve asset prices).

[0208] 2) Settlement: Assume Alice wins the bet. To claim her payout, she uses DECO to generate a ZKP whose retrieved current asset price matches her position. Alice and O then run the DECO protocol (with O acting as a verifier) ​​to obtain θ P Retrieves asset prices from (target URL). The response is (N * ,P * ,D * ) is included. Starting point θ P In addition to proving the ZKP in DECO, Alice proves the following statement:

number

[0209] If the proof validation is successful, the oracle returns the contract ID,

number

[0210] Alice and Bob need to trust O for its integrity, not for its privacy. They can further hedge against integrity flaws by using multiple oracles, as described elsewhere in this document. Decentralizing trust in oracles is a standard, already deployed technique. We emphasize that DECO ensures privacy even if all oracles are malicious.

[0211] As shown above, FIG. 11 shows the stock quote API request and response. The user (P) also needs to reveal enough parts of the HTTP GET request to the oracle (V) to be convinced to access the correct API endpoint. The GET request contains some parameters that are revealed, such as the API endpoint, and other parameters with sensitive details, such as the stock name, and a private API key. P uses the techniques disclosed herein to blackout the sensitive parameters and reveals the rest to V. The API key provides enough entropy to prevent V from learning the sensitive parameters. However, without additional precautions, a cheating P can hide his cheating by altering the semantics of the GET request and blacking out the extra parameters. To ensure that this does not happen, P needs to prove that the delimiters "&" and "=" do not appear in the blackout text.

[0212]

number

number

number

[0213] This two-step parsing is secure, assuming that the keys are unique and that the key "05.price" is followed by the price, and as described above, the grammar of this response is a key-value grammar with a unique key. Similarly, P proves that the stock name and date contained in R match the commitment. In the CBC-HMAC ciphersuite, the zero-knowledge proof circuit involves blacking out the entire record (408 bytes), computing the commitment, and string processing.

[0214] HTTP GET requests (and HTML) have a special restriction: the separator (i.e., the middle) between the key and the value, and the beginning (i.e., the start) of a key-value pair can never be a substring of the key or value. This means that to blackout two or more consecutive keys or values, P must blackout the {middle, start} characters. Therefore, the cons G,G’ (R,R') checks the following:(1)

number

number

number

number

[0215] Legacy Credentials to Anonymous Credentials: Age Proof. User credentials are often not accessible outside the service provider's environment. Some providers offer third-party API access via OAuth tokens, but such tokens reveal a user identifier. DECO allows users who hold credentials in existing systems (called "legacy credentials") to anonymously prove statements about them to a third party (a verifier). Thus, DECO in some embodiments allows users to convert any web-based legacy credentials to anonymous credentials without server-side support or trusted hardware.

[0216] Figure 12 shows an example of this application, where a student proves that she / he is over 18 years old using credentials (demographic details) stored on a university website. The student can provide this proof of age to any third party, such as the state issuing the driver's license or a hospital seeking consent for a medical test. We implement this example using the AES-GCM cipher suite and two-phase parsing with unique key based optimization.

[0217] In the example in Figure 12, the demographic details of a student stored on a university website include, among others, name, date of birth, and student ID. The highlighted text contains the student's age. Explicit mode is used with two-stage parsing. The prover parses 6-7 AES blocks containing the date of birth and proves to the verifier with ZK that her age is over 18. As with the other examples, this is also a key-value grammar with a unique key due to the unique HTML tags surrounding the date of birth. As with the binary options application, this example requires additional string processing to parse the date and time of calculation.

[0218] Price discrimination. Price discrimination refers to selling the same product or service at different prices to different buyers. Ubiquitous consumer tracking allows online shopping and booking websites to use sophisticated price discrimination, for example, adjusting prices based on a customer's zip code. Price discrimination is widely permitted under existing laws because it can lead to economic efficiency.

[0219] However, in the United States, the FTC prohibits price discrimination when it leads to competitive harm, while new privacy-focused laws in Europe, such as GDPR, are putting a renewed focus on the legality of the practice. In any case, consumers generally dislike being subject to price discrimination. However, there is currently no reliable way for users to report price discrimination online.

[0220] Figure 13 shows an example of this application, where DECO enables a buyer to make a verifiable claim about perceived price discrimination by proving that the advertised price of an item is higher than a threshold while concealing sensitive information such as name and address. We implement this example using the AES-GCM cipher suite preferred for the TLS session, and specify 24 AES blocks containing the required order details and the request URL.

[0221] As illustrated in Figure 13, part of an order invoice page in HTML for a shopping site (e.g., Amazon) contains personal details such as the buyer's name and address. The buyer wants to convince a third party (the verifier) ​​about the price charged for a particular product on a particular date. In this example, we use the AES-GCM encryption suite and display mode to reveal the required text at the top of the order invoice page, but the shaded sensitive text at the bottom, including the buyer's name, address, and city, is obscured. The number of AES blocks revealed from the response is 20 (due to the long product name). In addition, we reveal four AES blocks from the request to prove that the correct endpoint is being accessed. Context integrity is ensured by revealing unique strings around it, e.g. the string "Order Total:" near the product price, which appears only once in the entire response.

[0222] Implementation and Evaluation Here, we describe the implementation details and evaluation results of DECO and the three applications.

[0223] Three-party handshake and query execution. We implemented the TLS1.2 three-party handshake protocol (3P-HS) and query execution protocols (2PC-HMAC and 2PC-GCM) in approximately 4700 lines of C++ code. We constructed hand-optimized TLS-PRF circuits with a total AND complexity of 779,213. We also used a variant of a known AES circuit. Our implementation uses Relic for the Paillier cryptosystem and the EMP toolkit for a maliciously secure 2PC protocol.

[0224] To build an end-to-end system, we integrated the three-party handshake and 2PC-HMAC protocols with mbedTLS, a popular TLS implementation. 2PC-GCM can be integrated into TLS with similar engineering effort. We evaluated the performance of 2PC-GCM separately. The performance impact of the integration should be negligible. We did not implement 3P-HS for TLS1.3, but we believe that the performance should be comparable to that for TLS1.2, since the circuit complexity is similar.

[0225] We evaluated the performance of DECO in both LAN and WAN settings. Both the prover and verifier run on a c5.2xlarge AWS node with 8 vCPU cores and 16GB RAM. The two nodes were located in the same region (but different availability zones) for the LAN setting, but in two separate datacenters (Ohio and Oregon) for the WAN setting. The round trip times between the two nodes in LAN and WAN are around 1ms and 67ms, respectively, with a bandwidth of around 1Gbps.

[0226] Table 1 below summarizes the execution time of the DECO protocol during a TLS session. 50 samples were used to calculate the average and the standard error of the mean (in parentheses). The MPC protocol used relies on offline pre-processing to improve performance. The offline phase can be performed before the TLS session, since it is independent of the input and the target. Only the online phase is on the critical path. [Table 2]

[0227] As shown in Table 1, the DECO protocol is very efficient in a LAN setting. It takes 0.37 seconds to complete the three-party handshake. For query execution, 2PC-HMAC is efficient (0.13s per record) since it involves only one SHA-2 evaluation in 2PC, regardless of record size. 2PC-GCM is generally more expensive since it involves 2PC-AES throughout the query, with the cost depending on the query length. We evaluated the performance of 2PC-GCM for queries ranging from 256B to 2KB, which are typical sizes found in HTTP GET requests. In a LAN setting, the performance is efficient and comparable to 2PC-HMAC.

[0228] In WAN settings, the execution time is dominated by network latency since MPC involves multiple round-trip communications. Nevertheless, performance is still acceptable given that DECO is likely to be used regularly in most of the applications we consider.

[0229] Proof Generation. We instantiated zero-knowledge proofs with the standard proof system in libsnark. We devised efficiently provable statement templates, but users of DECO need to adapt these templates to their specific applications. The SNARK Compiler enables such adaptation in a high-level language, hiding the low-level details from the developer. We used xjsnark and its Java-like high-level language to build statement templates and libsnark-compatible circuits.

[0230] The reason for choosing libsnark is its relatively mature tooling support. Proofs generated by libsnark are constant size and very efficient to verify, with the drawback being the per-circuit trusted setup. DECO can be adapted to use, for example, Bulletproofs, which do not require a trusted setup but have large proof and verification times.

[0231] We measure five performance metrics for each example: prover time (time to generate a proof), verifier time (time to verify a proof), prover size, the number of arithmetic constraints in the circuit, and peak memory usage during proof generation.

[0232] Table 2 below summarizes the results. 50 samples were used to calculate the average and its standard error. Using efficient statement templates and two-stage parsing, DECO achieves very practical prover performance. Verifier time is negligible because libsnark is optimized for low verification overhead. Due to the extra string parsing routines, the number of constraints (and prover time) is highest for the binary options application. To reduce peak memory usage, we use multiple proofs for each application. For the most complex application, memory usage is 1.78GB. libsnark proofs are of constant size 287B, so the proof sizes shown are multiples of that. [Table 3]

[0233] End-to-end performance. DECO end-to-end performance depends on the available TLS cipher suites, the size of the private data, and the complexity of the application-specific proofs. Here we present the end-to-end performance of the most complex application of the three we implemented: binary options. It takes about 13.77 seconds to finalize the protocol, which includes the time taken to generate a non-forgeable commitment (0.50 seconds), perform the first stage of the two-phase parsing (0.30 seconds), and generate the zero-knowledge proof (12.97 seconds). These figures are calculated in a LAN setting; in a WAN setting, the MPC protocol takes longer (5.37 seconds), pushing the end-to-end time to 18.64 seconds.

[0234] In comparison, Town Crier runs a similar application using a TEE in about 0.6 seconds, or roughly 20 times faster than DECO, but with additional trust assumptions. Given that DECO is likely to be used only periodically in most applications, the overhead of DECO to achieve crypto-strength security guarantees seems reasonable.

[0235] Legal and Compliance Issues Although users may have already extracted their data from the website, DECO allows users to export the data along with an integrity certificate without their explicit approval or even knowledge. We now briefly discuss the resulting legal and compliance considerations.

[0236] However, it is crucial that DECO users cannot unilaterally export data with integrity guarantees to third parties, but rely on oracles as validators for this purpose. DECO keeps user data private, but the oracles know what websites and data types users access. Thus, the oracles can enforce proper data usage, for example rejecting transactions that may result in copyright infringement.

[0237] Both users and oracles are legally responsible for the data they access. However, recent case law regarding the Computer Fraud and Abuse Act (CFAA) marks a shift away from the criminalization of web scraping, with federal courts holding that violating a website's terms of use is not, in and of itself, a criminal act. Users and oracles that violate a website's terms of use (such as "clickwrap") instead risk civil penalties. DECO's compliance with a given site's terms of use is a site- and application-specific matter.

[0238] Oracles have an incentive to establish themselves as trustworthy within smart contracts and other ecosystems. A reputable oracle will provide users with a menu of specific certificates it will issue and target websites it will allow, and will expect users to vet these options to maximize security, minimize liability, and potentially notify or cooperate with the target server.

[0239] The legal, performance, and compliance implications of erroneous certifications based on erroneous data are also significant. However, these issues are not unique to DECO, as current Internet services have complex multi-site data dependencies. Oracle services already rely on multiple data sources to help ensure accuracy. Oracle services in general may eventually produce an infrastructure like that for certificates, including online checking and revocation capabilities, as well as different layers of security.

[0240] DECO, in example embodiments disclosed herein, is a privacy-preserving decentralized oracle scheme for modern TLS versions that does not require trusted hardware or server-side modifications. DECO enables a prover to generate unforgeable commitments for TLS sessions and efficiently prove statements about session contents. Some embodiments utilize a novel two-phase parsing scheme to mitigate context integrity attacks that are pervasive in privacy-preserving oracles. DECO can liberate data from centralized web service silos and make this data accessible to a wide range of applications. The practicality of DECO is demonstrated herein through a fully functional implementation along with three example applications.

[0241] GCM protocol details GCM is an authenticated encryption with additional data (AEAD) cipher. To encrypt, the GCM cipher takes a tuple

number

number

[0242] The ciphertext is computed in counter mode:

number

[0243] tag

number

number

number

number

number

number

number

number

[0244] When using GCM in TLS, each plaintext record D is encrypted as follows: a unique nonce n is chosen, and additional data κ is computed as the concatenation of the sequence number, the version, and the length of D. GCM encryption is invoked to produce a payload record as M = n||GCM(k,n,D,κ).

[0245] Additional details regarding GCM can be found, for example, in Morris J Dworkin, SP 800-38d, “Recommendation for block cipher modes of operation: Galois / counter mode (GCM) and GMAC,” Technical Report, 2007, which is incorporated herein by reference.

[0246] Query execution Tag Creation / Verification. Computing or verifying a GCM tag involves evaluating equation (1) above in 2PC. The challenge is that equation (1) requires arithmetic calculations (e.g.,

number

number

number

[0247] Our protocol eliminates the need for polynomial evaluation: the actual 2PC protocol involves only binary arithmetic and can therefore be done with a single circuit. Moreover, the computation per record is reduced to only one invocation of 2PC-AES.

[0248] This is done in the preprocessing phase at the beginning of the session. i This is achieved by computing the share of {h i}, P and V are the shares of the polynomial evaluation

number

number

[0249] It is crucial that V never responds to the same IV more than once, otherwise P would learn h. Specifically, in each response, V

number

number

number

[0250] Encrypting / Decrypting Records. Once the tags have been properly checked, decrypting a record is straightforward. P and V simply compute the AES encryption of inc'(IV) using 2PC-AES. A minor caveat is that V must check that the counter being encrypted has not been used as an IV before. Otherwise, P will know h for P in the fashion outlined above.

[0251] Proof Generation Block specification. P is AES block B i We want to convince V that AES block B is the i-th block of the encrypted record rec. The proof strategy is as follows: i is the ciphertext block

number

[0252] We successfully achieve a much more efficient proof by allowing P to reveal the two encrypted messages, AES(k,IV) and AES(k,0), to V, and thus allowing V to verify the tag (see equation (1)). P only needs to prove the correctness of the encryption in ZK and that the key used corresponds to the commitment, requiring two rounds of AES and one round of SHA-2 (P can prove k by revealing the hash of the key). P(The total cost is therefore 3 times AES and 1 time SHA-2 in the ZKP.

[0253] Manifesting a TLS Record. The proof technique is a simple extension from the above case: P proves the entire record rec and proves correct AES encryption of all AES blocks, resulting in a total of 514 AES and 1 SHA-2 in the ZKP.

[0254] Manifestation of a TLS record except for a block. As in the above case, P proves the encryption of all blocks in the record except for one, resulting in a total of 513 AES and 1 SHA-2 in the ZKP.

[0255] Protocol Extensions Adaptation for TLS1.3 support. To support TLS1.3, the 3P-HS protocol has to be adapted to a new handshake flow and a different key derivation circuit. In particular, now all handshake messages after the ServerHello are encrypted. A naive strategy would decrypt them in 2PC, which would be costly since certificates are usually large. However, thanks to the key independence property of TLS1.3, P and V can securely reveal the handshake encryption keys without affecting the secrecy of the final session key. The finished messages authenticate the handshake using yet another independent key, so the handshake integrity is preserved.

[0256] Thus, the optimized 3P-HS works as follows: P and V run the same ECDHE as before. They then derive the handshake and application keys by running 2PC-HKDF, and reveal the handshake keys to P, allowing P to decrypt the handshake messages locally (i.e., without 2PC). The 2PC circuit involves about 30 invocations of SHA-256 totaling about 70k AND gates, comparable to that of TLS1.2. Finally, DECO can only be used in GCM mode, since CBC-HMAC is not supported by TLS1.3.

[0257] Query construction is optional. For applications that bind responses to queries, such as to include stock tickers with trading prices, the 2PC query construction protocol can be avoided entirely. Since TLS uses separate keys for each direction of communication, the client-to-server key can be made explicit to P after the handshake, such that P can query the server without interacting with V.

[0258] Support for multi-round sessions. DECO can be extended to support multi-round sessions, where P sends further queries depending on previous responses. After each round, P runs a 2PC protocol similar to the one above to verify the MAC tag of the incoming response, since MAC verification and creation are symmetric. However, an additional commitment is required to prevent P from exploiting MAC verification to forge tags.

[0259] In TLS, different MAC keys are used for server-to-client and client-to-server communications. To support multi-round sessions, P and V perform 2PC to verify the tag of the former and create a fresh message tag for the latter. The previous discussion in this document specified the protocol to create (and verify) MAC tags. We now discuss additional security considerations for multi-round sessions.

[0260] When checking the tags of messages from the server to the client, we must ensure that P cannot forge the tags of messages that do not originate from the server. Suppose P wants to verify the tag T of a message M. Let P first commit to T, then P and V run the 2PC protocol to compute the tag T' of message M. P is asked to open a commitment to V, and if T ≠ T', V aborts the protocol. Since P does not know the MAC key, P cannot compute and commit to the tag of a message that does not come from the server.

[0261] When creating tags for messages from the client to the server, V ensures that MAC tags are created for messages with incremented sequence numbers, as required by TLS. This also prevents a malicious P from creating two messages with the same sequence number, since V has no way to distinguish which message was sent to the server.

[0262] Alternative DECO Protocol: Proxy Mode. As shown in Table 1, the HMAC mode of DECO is very efficient, and the execution time of creating and verifying an HMAC tag with 2PC is independent of record size. The GCM mode is efficient for small requests with preprocessing, but can be expensive for large records. Here we present a highly efficient alternative that avoids the post-handshake 2PC protocol altogether.

[0263] In this alternative, a verifier V acts as a proxy between a prover P and a TLS server S, i.e., P sends / receives messages to / from S through V. The modified flow of the DECO protocol is as follows: After the three-party handshake, P obtains a key share k P Then, V commits to k V Therefore, P is now a session key k=k P +k V As P continues its session with server k, V records its proxy traffic. After the session ends, P proves that its recorded statements about the session are the same as before.

[0264] In such an embodiment, the three-party handshake provides unforgeability. Unlike CBC-HMAC, GCM does not commit: for a given ciphertext and tag (C, T) encrypted with key k, it is possible to find k' ≠ k that decrypts C to a different plaintext while computing the same tag, since GCM MAC is not collision-resistant. To prevent such attacks, the above protocol requires that P commits to a key share before learning the session key.

[0265] We now describe the security properties and network assumptions relevant to the proxy mode protocol. The verifier integrity and privacy properties are well-defined, since a malicious V cannot break TLS integrity and privacy.

[0266] However, for prover integrity, we need to assume that the proxy can reliably connect to S throughout the entire session. First, we assume that the proxy can verify that it is reliably connected to S. Furthermore, we assume that P, which knows the session key and can therefore modify the session contents, cannot tamper with messages sent between the proxy and S.

[0267] During the three-party handshake, V can verify the server's identity by checking the server's signature over a fresh nonce (in standard TLS). However, after the handshake, V must rely on network-layer indicators such as IP addresses. In practice, therefore, V must have correct, up-to-date DNS records, and the networks between V and the server (e.g., their ISPs and backbone networks) must be adequately protected against traffic injection, e.g., through Border Gateway Protocol (BGP) attacks. Eavesdropping is generally not an issue in the exemplary embodiment.

[0268] These assumptions are accepted by other systems in similar proxy settings, since BGP attacks are difficult to mount in practice. The protocol can be further hardened against traffic interception by geographically distributing the verifier nodes. Furthermore, various known detection techniques can be deployed by the verifiers. In many cases, BGP attacks are documented after the fact, and therefore, where applicable, the application of DECO can be hardened to support revocation of affected sessions (e.g., when using DECO in an identity information system to issue credentials).

[0269] This alternative protocol represents a different performance-security trade-off: it is highly efficient since no intensive cryptography occurs after the handshake, but it requires additional assumptions about the network and is therefore only resistant to weaker network adversaries.

[0270] Key-Value Grammars and Two-Phase Parsing Preparation and Notation. Denote a context-free grammar (CFG) as G = (V, Σ, P, S), where V is the set of non-terminal symbols, Σ is the set of terminal symbols, and P:V → (V ∪ Σ). *is a set of productions or rules, and S∈V is the start symbol. We define the production rules of a CFG in standard notation, using "-" to represent a negative set and ".." to represent a range. For a string w, the parser determines whether w∈G by constructing a parse tree for w. The parse tree represents a set of production rules that can later be used to extract semantics.

[0271] Key-value grammars. These are grammars that have a notion of key-value pairs. These grammars are of particular interest to DECO because most API calls and responses are in fact key-value grammars.

[0272] G is said to be a key-value grammar if there exists a grammar H such that for any s ∈ G, s ∈ H, and H, it can be defined by the following rules: S → object object→noPairsString open pair pairs close pair→start key middle value end pairs → pair pairs|“”(pairs → pair pairs|””) Key → chars value → chars | object String→Character String|“”(chars→char chars|””) char → Unicode - escaped|escape escaped|addedChars Special→Start Special|Middle Special|End Special (special→startSpecial|middleSpecial|endSpecial) Start → Unescaped s Start special (start→unescapeds startSpecial) Intermediate → Non-escaping m Middle special (middle→unescaped m middleSpecial) End → Unescaped e End Special (end→unescaped e endSpecial) escaped→special|escape|...

[0273] In the above, S is a start non-terminal (representing a sentence in H), the non-terminal open and close delimit the open and close of a set of key-value pairs, and the start, middle, and end are special strings that delimit the start of a key-value pair, the separation between the key and the value, and the end of the pair.

[0274] For special characters, i.e. characters that have a special meaning when parsing the grammar, special nonterminal escapes are used to remove ambiguity when parsing. For example, in JSON, keys are parsed if they are preceded by a "whitespace double quote" (") and followed by a double quote. If the key or value expressions themselves must contain double quotes, they must be preceded by a backslash (\), i.e. escaped. In the rules above, unescaped nonterminals before special characters mean that they can be parsed as special characters. So going forward, we can assume that there is no ambiguity in the generation of key-value pairs. So if a substring R' of a string R in a key-value grammar G parses as a pair, then R' must correspond to a pair in the parse tree of R.

[0275] In the above key-value grammar, the middle cannot derive an empty string, i.e., a non-empty string must mark the middle to make it possible to parse the key from the value. However, one of the start and end can derive an empty string, since it only delimits the separation between the values ​​of one pair from the key of the next pair. Finally, in some embodiments, a two-phase parse for a key-value grammar involves the derivation of an optional disclosed string, R open Note that we only consider admissible paths with the requirement that x corresponds to a pair.

[0276] Two-phase parsing of locally unique keys. Many key-value grammars enforce uniqueness of keys within a certain range. For example, in JSON, keys can be made unique within a JSON object, even though there may be duplicate keys across objects. The two-phase parsing for such grammars can be reduced to parsing substrings. Specifically, Trans extracts contiguous substrings R' from R such that it can correctly determine the range of pairs even within R'. For example, in JSON, cons is a scalar if and only if R' is a prefix of R. G,G’ If (R,R') returns true, then R open We can get the string R by simply parsing R' as JSON until we produce a subtree that gives rise to open corresponds to the correct context in R.

[0277] Grammars with unique keys. Given a key-value grammar G, u G We define a function to check the uniqueness of keys, denoted as k. We define a string s ∈ G and another string k,u if and only if there exists at most one substring of s that can be parsed as k intermediate. G Given that (s, k) = true. Since s ∈ G, this means that in any parse tree of s, there exists at most one branch with node key and derivation k. GLet be a function that returns true if the input is in grammar G. Grammar G is a set of all possible keys k, u G We say that a grammar has a unique key if (s, k) = true, i.e., for all strings R, C, we say that a grammar has a unique key if:

number

[0278] Set a context function CTX for T such that T contains admissible paths to pairs of strings in U. U In addition, CTX U As an auxiliary constraint, the key k (the output R open The tuple (T, k) is a set of S and CTX U (S,·,·)CTX U,S This is expressed as:

[0279] P, rule S P Let U be a grammar given by pairs, where pairs are non-terminals of the production rules of U, and S P is the start symbol of P. P,k Define P as a function that determines whether a string s is in P, and if so, whether the key of s is equal to k. Given inputs R, R open If there is, CTX U,S Check the following:(a) R open Parser P,k (b) R open as a key-value pair in R by running the LL(1) parsing algorithm to parse R.

[0280] FIG. 14 illustrates the process of parsing a string R in a key-value grammar U and finding a particular key-value pair Ropen A function CTX for searching the generation of U,S Here, a PTable, which is the LL(1) parsing table of U, is U,S is hard-coded to

[0281] CTX on long string R U、S To avoid the expensive calculation of R'=R according to the requirement open We introduce a transformation Trans to extract a substring R' of R such that

[0282] We also define functions substring(s,t) that return true if t is a substring of s, and equal(s,t) that return true if s=t. U,P :

number

number

[0283] Regarding S (cons U,P , S') is correct. More specifically, if R' is a substring of R then there is a key-value pair R open Parser P Then, the same pair must be a substring of U. Due to the global uniqueness of the keys in U, there is no such pair R open There is only one CTX U (S,R,R open ) must be true.

[0284] Embodiments may utilize alternative protocol arrangements in implementing the decentralized oracles disclosed herein.

[0285] As indicated above, the exemplary embodiments of the decentralized oracle disclosed herein can be implemented in a wide variety of different applications.

[0286] For example, DECO can be used to implement a personal data marketplace where users manage and sell their personal data. It is well known that web services make money by monetizing user data. A personal data marketplace implemented using the technology disclosed herein can disrupt this data monopoly by allowing users to sell data in an open market. DECO, in an example embodiment, is a key enabler of the personal data marketplace because it allows buyers to verify the origin and integrity of the data from the website. DECO also allows sellers to pre-process the data, such as redacting sensitive information for privacy protection, while preventing sellers from committing fraud. In some implementations, DECO is utilized to provide a verifiable claim for price discrimination.

[0287] As another example, DECO can be used to provide proof of financial solvency. As a more concrete illustration of this type of arrangement, DECO can be used by Alice to prove to Bob that her balance at a particular bank is over $5000. This simple proof not only demonstrates Alice's financial solvency, but also her ability to open an account (e.g., that Alice is not on a sanctions list when the bank conducts anti-money laundering (AML) screening). Importantly, DECO preserves Alice's privacy by revealing only the fact that her balance is over $5,000, and not her actual balance or identity.

[0288] As a further example, DECO can be used to provide proof of account ownership. In one such arrangement, DECO can be used to anonymously prove ownership of an account, e.g., email account, social media account. For example, Alice can prove to Bob that she owns an email account ending in @example.org without having to specify what the account name is. This proves that Alice belongs to a particular organization, which is useful, e.g., for whistle-blowing, anonymous complaints, etc.

[0289] Additional examples of applications of decentralized oracles disclosed herein include credential recovery and decentralized identity. As an example of the former, DECO can allow a user to prove in a privacy-preserving manner that avoids the use of OAUTH that she can access a particular web resource, e.g., her Facebook account. This can allow the user to leverage existing services to prove her identity, e.g., for key recovery. As an example of the latter, DECO can also allow a user to prove in a privacy-preserving manner that she has certain characteristics as asserted by a third-party provider (e.g., she is over 18 years old). This is an example of what is referred to herein as anonymous age proof. Such proof can be used to build credentials in a decentralized identity system.

[0290] The foregoing decentralized oracle applications are merely examples and are not to be construed as limiting in any way. Additional details regarding implementation aspects of these and other exemplary applications of the decentralized oracle disclosed herein may be found elsewhere herein.

[0291] Communication between various elements of an information processing system configured to implement one or more decentralized oracles disclosed herein may occur over one or more networks, whereby any such network may illustratively include, for example, the Internet, a WAN, a LAN, a satellite network, a telephone or cable network, a cellular network such as a 3G, 4G, or 5G network, a wireless network implemented using a wireless protocol such as Bluetooth, WiFi, or WiMAX, or various portions or combinations of these and other types of communication networks.

[0292] A given processing device implementing at least a portion of the functionality of the decentralized oracle disclosed herein may include components such as a processor, a memory, and a network interface. The processor is operatively coupled to the memory and to the network interface. The memory stores software program code for execution by the processor in implementing a portion of the functionality of the processing device.

[0293] It should be appreciated that the particular arrangements shown and described herein in conjunction with FIGS. 1-14 are presented merely as illustrative examples, and that numerous alternative embodiments are possible. Thus, the various embodiments disclosed herein are not to be construed as limiting in any manner. Numerous alternative arrangements for implementing a decentralized oracle may be utilized in other embodiments. For example, one skilled in the art will recognize that alternative processing operations and associated system entity configurations may be used in other embodiments. Thus, it is possible that other embodiments may include additional or alternative system entities as compared to the entities of the illustrative embodiments. Also, the particular system and device configurations and associated decentralized oracles may vary in other embodiments.

[0294] It should also be noted that the information handling system arrangements described above are merely exemplary, and that alternative system configurations may be used in other embodiments.

[0295] A given client, server, processor, or other component in the information processing systems described herein is illustratively configured with a corresponding processing device that includes a processor coupled to a memory. The processor executes software program code stored in the memory to control the performance of processing operations and other functionality. The processing device also includes a network interface that supports communication over one or more networks.

[0296] A processor may comprise, for example, a microprocessor, an ASIC, an FPGA, a CPU, a GPU, an ALU, a DSP, or other like processing device components, as well as other types and arrangements of processing circuitry in any combination. For example, at least a portion of the functionality of a decentralized oracle provided by a given processing device disclosed herein may be implemented using such circuitry.

[0297] The memories store software program code for execution by the processor in implementing a portion of the functionality of the processing device. A given such memory storing such program code for execution by a corresponding processor is an example of what is referred to herein more generally as a processor-readable storage medium in which the program code is embodied, and may comprise, for example, electronic memory such as SRAM, DRAM, or other types of RAM, ROM, flash memory, magnetic memory, optical memory, or other types of storage devices, in any combination.

[0298] An article of manufacture comprising such a processor-readable storage medium is considered an embodiment of the present invention. As used herein, the term "article of manufacture" shall be understood to exclude ephemeral propagating signals.

[0299] Other types of computer program products comprising a processor-readable storage medium may be implemented in other embodiments.

[0300] Additionally, embodiments of the present invention may be implemented in the form of an integrated circuit comprising processing circuitry configured to implement the processing operations associated with a decentralized oracle, as well as other related functionality.

[0301] The processing devices in a given embodiment may include, for example, laptops, tablet or desktop personal computers, mobile phones, or other types of computers or communication devices in any combination. For example, a computer or mobile phone may be utilized as a processing device to implement at least a portion of the functionality associated with the decentralized oracle disclosed herein. These and other communications between the various elements of the information processing system with the processing devices associated with the respective system entities may occur over one or more networks.

[0302] The information processing systems disclosed herein may be implemented using one or more processing platforms, or portions thereof.

[0303] For example, one exemplary embodiment of a processing platform that may be used to implement at least a portion of an information processing system comprises a cloud infrastructure including virtual machines implemented using a hypervisor running on a physical infrastructure. Such virtual machines may comprise respective processing devices that communicate with each other over one or more networks.

[0304] The cloud infrastructure in such an embodiment may further comprise one or more sets of applications running on respective virtual machines under the control of the hypervisor. It is also possible to use multiple hypervisors, each providing a set of virtual machines, using at least one underlying physical machine. Different sets of virtual machines provided by one or more hypervisors may be utilized in configuring multiple instances of various components of the information processing system.

[0305] Another exemplary embodiment of a processing platform that may be used to implement at least a portion of an information processing system disclosed herein comprises a plurality of processing devices in communication with each other via at least one network, each processing device of the processing platform comprising a processor coupled to a memory.

[0306] Again, these particular processing platforms are presented merely as examples, and the information processing system may include additional or alternative processing platforms, as well as multiple individual processing platforms in any combination, each such platform comprising one or more computers, servers, storage devices, or other processing devices.

[0307] For example, other processing platforms used to implement embodiments of the invention may comprise different types of virtualization infrastructure instead of, or in addition to, a virtualization infrastructure that comprises virtual machines. Thus, in some embodiments, system components are capable of operating at least in part on a cloud infrastructure or other type of virtualization infrastructure, including a virtualization infrastructure that utilizes Docker containers, or other types of Linux containers implemented using operating system-level virtualization based on Linux control groups or other similar mechanisms.

[0308] It should therefore be understood that in other embodiments, different arrangements of additional or alternative elements may be used, with at least a subset of these elements being collectively implemented on a common processing platform, or each such element being implemented on a separate processing platform.

[0309] Also, numerous other configurations of computers, servers, storage devices, or other components are possible in an information handling system, and such components may be in communication with other elements of the information handling system via any type of network or other communications medium.

[0310] As previously indicated, components of the systems disclosed herein may be implemented, at least in part, in the form of one or more software programs stored in a memory and executed by a processor of a processing device. For example, certain functionality associated with a decentralized oracle entity or related components of the system may be implemented, at least in part, in software.

[0311] The particular configurations of information processing systems described herein are exemplary only, and in other embodiments a given such system may include other elements in addition to or in place of those specifically shown, including one or more elements of a type commonly found in conventional implementations of such systems.

[0312] For example, in some embodiments, information processing systems may be configured to utilize the disclosed techniques to provide additional or alternative functionality in other contexts.

[0313] Thus, in some embodiments herein, techniques illustrated in the context of providing a decentralized oracle for TLS can be adapted in a straightforward manner for use in other contexts, and thus, the exemplary embodiments of the present invention should not be considered limited to TLS or its associated processing context.

[0314] It should also be appreciated that the particular process steps used in the embodiments described herein are merely exemplary, and that other embodiments may utilize different types and arrangements of processing operations. For example, certain process steps shown to be performed sequentially in the exemplary embodiments may be performed at least partially in parallel with one another in other embodiments.

[0315] It is again emphasized that the embodiments of the invention described herein are merely exemplary. Other embodiments of the invention can be implemented utilizing a wider variety of different types and arrangements of information processing systems, networks, and devices than are utilized in the specific exemplary embodiment described herein, and in numerous alternative processing contexts. In addition, certain assumptions made herein in the context of describing a specific embodiment need not apply to other embodiments. These and numerous other alternative embodiments will be readily apparent to those skilled in the art.

Claims

1. An apparatus comprising: a verifier device comprising a processor coupled to a memory; the verifier device is configured to communicate with client devices and server devices over one or more networks; the verifier device: receiving, from the client device, a commitment of cryptogram associated with the secure session with the server device; verifying accuracy of at least one characterization of data obtained by the client device from the server device as part of the secure session based at least in part on the commitment; [0023] 20. The method according to claim 1, further comprising: the verifier device is further configured to act as a proxy for the client device in conjunction with interactions between the client device and the server device, whereby the verifier device automatically obtains cryptograms exchanged between the client device and the server device as part of the secure session via the verifier device acting as the proxy. Device.

2. 2. The apparatus of claim 1, wherein the verifier device is further configured to initiate one or more automated actions in response to the verification of the accuracy of the at least one characterization of the data obtained by the client device from the server device.

3. The apparatus of claim 1 , wherein the verifier device comprises a particular oracle node of a set of oracle nodes of a decentralized oracle system.

4. The apparatus of claim 1 , wherein the verifier device comprises a distributed verifier device in which functionality of the verifier device is distributed across multiple separate processing devices.

5. The apparatus of claim 1 , wherein the server device comprises a Transport Layer Security (TLS) enabled server device, and the secure session comprises a TLS session.

6. The apparatus of claim 1 , wherein the commitments associated with the secure session include commitments to query response data obtained by the client device from the server device as part of the secure session.

7. 2. The apparatus of claim 1, wherein the verifier device is further configured to receive from the client device one or more statements characterizing the data obtained by the client device from the server device as part of the secure session.

8. 8. The apparatus of claim 7, wherein a given one of the one or more statements comprises a selectively explicit substring of query response data obtained by the client device from the server device as part of the secure session.

9. 10. The apparatus of claim 8, wherein a given one of the one or more statements is configured to provide context integrity through utilization of a multi-stage parsing protocol, and wherein query response data obtained by the client device from the server device as part of the secure session is pre-processed by the client device to generate reduced data that is subsequently parsed by the client device in conjunction with generating the given statement that is sent by the client device to the verifier device.

10. verifying accuracy of at least one characterization of data obtained by the client device from the server device as part of the secure session; obtaining data derived from at least a portion of at least one ciphertext of the secure session; verifying, by the client device, the accuracy of at least one characterization of the data; The apparatus of claim 1 , comprising:

11. 1. A method performed by a verifier device configured to communicate with a client device and a server device over one or more networks, comprising: receiving, from the client device, a commitment of cryptogram associated with the secure session with the server device; in response to receiving the commitment, revealing to the client device additional information relating to the secure session that was not previously accessible to the client device; verifying accuracy of at least one characterization of data obtained by the client device from the server device as part of the secure session based at least in part on the commitment; Including, The verifier device for performing the method comprises a processor coupled to a memory; the verifier device is further configured to act as a proxy for the client device in conjunction with interactions between the client device and the server device, whereby the verifier device automatically obtains cryptograms exchanged between the client device and the server device as part of the secure session via the verifier device acting as the proxy. method.

12. verifying accuracy of at least one characterization of data obtained by the client device from the server device as part of the secure session; obtaining data derived from at least a portion of at least one ciphertext of the secure session; verifying, by the client device, the accuracy of at least one characterization of the data; The method of claim 11 , comprising:

13. 12. The method of claim 11, further comprising initiating one or more automated actions in response to the verification of the accuracy of the at least one characterization of the data obtained by the client device from the server device.

14. The method of claim 11 , wherein the commitments associated with the secure session include commitments to query response data obtained by the client device from the server device as part of the secure session.

15. The method of claim 11 , further comprising receiving, as part of the secure session, one or more statements from the client device characterizing the data obtained by the client device from the server device.

16. 1. A computer program product comprising: a non-transitory processor-readable storage medium having program code stored therein of one or more software programs, the program code, when executed by a verifier device configured to communicate with client devices and server devices over one or more networks, the verifier device including a processor coupled to a memory, causing the verifier device to: receiving, from the client device, a commitment associated with the secure session with the server device; in response to receiving the commitment, revealing to the client device additional information relating to the secure session that was not previously accessible to the client device; verifying accuracy of at least one characterization of data obtained by the client device from the server device as part of the secure session based at least in part on the commitment; Let them do so, the verifier device is further configured to act as a proxy for the client device in conjunction with interactions between the client device and the server device, whereby the verifier device automatically obtains cryptograms exchanged between the client device and the server device as part of the secure session via the verifier device acting as the proxy. Computer program products.

17. verifying accuracy of at least one characterization of data obtained by the client device from the server device as part of the secure session; obtaining data derived from at least a portion of at least one ciphertext of the secure session; verifying, by the client device, the accuracy of at least one characterization of the data; 20. The computer program product of claim 16, comprising:

18. 20. The computer program product of claim 16, wherein the program code, when executed by the verifier device, causes the verifier device to initiate one or more automated actions in response to the verification of the accuracy of the at least one characterization of the data obtained by the client device from the server device.

19. 20. The computer program product of claim 16, wherein the commitments associated with the secure session include commitments for query response data obtained by the client device from the server device as part of the secure session.

20. 20. The computer program product of claim 16, wherein the program code, when executed by the verifier device, causes the verifier device to receive from the client device one or more statements characterizing the data obtained by the client device from the server device as part of the secure session.

Images