Distributed techniques for authenticating data in transport layer security and other contexts

Abstract

A verifier device in one embodiment is configured to communicate with a client device and a server device via one or more networks. The verifier device participates in a three-party handshake protocol with the client device and the server device in which 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 submission from the client device related to the secure session with the server device and, in response to receiving the submission, releases additional information to the client device related to the secure session that was previously inaccessible by the client device. The verifier device verifies, based at least in part on the submission and the additional information, the correctness of at least one representation of data obtained by the client device from the server device as part of the secure session.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 62 / 894,052, filed August 30, 2019, entitled “DECO: Decentralized Oracles for TLS,” the entire contents of which are incorporated herein by reference.

[0003] Government Support Statement

[0004] This invention was carried out with the support of the U.S. government under National Science Foundation (NSF) licenses CNS-1514163, CNS-1564102, CNS-1704615, and CNS-1933655 and Army Research Office (ARO) license W911NF161-0145. The U.S. government owns certain rights to this invention. Technical Field

[0005] This field generally relates to information security, including techniques for, for example, proving that data originates from a particular source or otherwise verifying the correctness of data obtained in the context of Transport Layer Security (TLS) and in other contexts. Background Technology

[0006] Thanks to the widespread deployment of TLS, users can access private data via channels with end-to-end confidentiality and integrity. However, what users cannot do is prove the origin of this data to third parties—that is, whether it truly comes from a specific website. Existing methods introduce undesirable trust assumptions or require server-side modifications. As a result, the value of a user's private data is locked to its point of origin. Summary of the Invention

[0007] The illustrative embodiments provide decentralized oracles for TLS and in many other applications where proof that data originates from a specific source is required or otherwise necessary.

[0008] For example, some embodiments overcome the aforementioned drawbacks of existing methods by providing a distributed oracle (illustratively referred to herein as a DECO) that allows a user to prove that a piece of data accessed via TLS originates from a specific website, and optionally prove statements about such data with zero knowledge, thereby maintaining the data's own secrecy. The DECO can thus release data from a centralized network service repository, making it accessible to a wide range of applications. Advantageously, the DECO in the illustrative embodiments operates without trusted hardware or server-side modifications.

[0009] In one embodiment, the device includes a validator device comprising a processor and memory coupled to the processor. The validator device is configured to communicate with a client device and a server device via one or more networks. The validator device participates in a three-way handshake protocol with the client device and the server device, wherein the validator device and the client device obtain a corresponding shared session key for a secure session with the server device. The validator device receives a commit from the client device related to the secure session with the server device, and in response to receiving the commit, releases additional information to the client device related to the secure session that was previously inaccessible to the client device. The validator device verifies, at least in part, the correctness of at least one representation of data obtained by the client device from the server device as part of the secure session based on the commit and the additional information.

[0010] It should be understood that the above arrangement is merely an example, and many alternative arrangements are possible.

[0011] These and other embodiments of the present invention include, but are not limited to, systems, methods, apparatuses, processing devices, integrated circuits, and processor-readable storage media having software program code embodied therein. Attached Figure Description

[0012] Figure 1 An information processing system for a distributed oracle used in TLS is illustrated in an illustrative embodiment.

[0013] Figure 2 This is a flowchart illustrating the process of implementing a distributed oracle for TLS in an illustrative embodiment.

[0014] Figure 3 Examples of distributed oracle functionality are shown in illustrative embodiments.

[0015] Figure 4 This illustrative embodiment describes multiple stages of device interaction in a distributed oracle implementation that includes a server device, a prover device, and a validator device.

[0016] Figure 5 The illustrative embodiments include instance data of bank statement information used to demonstrate selective openness and context integrity attacks.

[0017] Figure 6 A detailed view of one possible implementation of a distributed oracle protocol in an illustrative embodiment is shown.

[0018] Figure 7 A detailed example of a three-way handshake protocol for implementing a distributed oracle is shown in the illustrative embodiments.

[0019] Figure 8The protocol for establishing key sharing between the certifier device and the verifier device is illustrated in the illustrative embodiment.

[0020] Figure 9 and 10 Additional instances of protocols utilized in the implementation of the distributed oracle in the illustrative embodiments are shown.

[0021] Figure 11 This demonstrates a smart contract implementation involving two parties, where one of those parties utilizes a decentralized oracle to obtain information provided to the smart contract.

[0022] Figure 12 and 13 The illustrative embodiments demonstrate instance data processed using corresponding redact patterns of one or more distributed oracles.

[0023] Figure 14 The pseudocode for two-stage parsing of the unique key syntax is shown in the illustrative embodiment. Detailed Implementation

[0024] Embodiments of the present invention may be implemented, for example, as information processing systems comprising other arrangements including computer networks or networks, clients, servers, processing devices, and other components. Illustrative embodiments of such systems will be described in detail herein. However, it should be understood that embodiments of the present 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. Therefore, the term "information processing system" as used herein is intended to be broadly understood to encompass these and other arrangements.

[0025] Figure 1 An information processing system 100 implementing a distributed oracle for TLS is illustrated in an illustrative embodiment. System 100 includes a plurality of client devices 102-1, 102-2…102-N and a validator device 104, the client devices and the validator device being configured to communicate via a network 105. A given client device 102 may include, for example, a laptop computer, tablet computer, or desktop personal computer, a mobile phone, or another type of computer or processing device, as well as combinations of multiple such devices. The validator device 104 may similarly include various types of processing devices, each processing device comprising at least one processor and at least one memory coupled to said at least one processor.

[0026] Network 105 may illustratively include, for example: global computer networks such as the Internet, wide area networks (WANs), local area networks (LANs), satellite networks, telephone or cable television networks; cellular networks such as 3G, 4G or 5G networks; wireless networks implemented using wireless protocols such as Bluetooth, WiFi or WiMAX, or various parts or combinations of these and other types of communication networks.

[0027] System 100 further includes a plurality of TLS servers 106 associated with respective protected data sources 108. The TLS servers 106 are illustratively configured to control access to their respective protected data sources 108. At least a subset of the protected data sources 108 illustratively includes corresponding websites with HTTPS functionality, where HTTPS stands for Secure Hypertext Transfer Protocol, an extension of Hypertext Transfer Protocol (HTTP). It should be understood that a wide variety of additional or alternative data sources may be used in other embodiments. The protected data source 108 of system 100 is protected in the sense that it can 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 be subject to additional or alternative access control mechanisms, and / or may be openly accessible using other types of security protocols.

[0028] Furthermore, while the illustrative embodiments herein utilize one or more servers of a particular type (e.g., TLS server 106), it should be understood that other types of security protocols may be used in other embodiments and may be implemented in other types of server apparatuses. Therefore, the term "server apparatus" as used herein is intended to be understood broadly and should not be construed as being limited in any way to a TLS server.

[0029] In some embodiments, client device 102 operates as a corresponding prover device relative to validator device 104 or other zero-knowledge proof (ZKP) oracle node 110 of system 100. Thus, validator device 104 can be considered as a ZKP oracle node of system 100. Therefore, a given “validator device” as used extensively herein can include, for example, a specific oracle node in a set of oracle nodes in a decentralized oracle system (e.g., system 100).

[0030] The specific number, type, and arrangement of devices and other components in system 100 are presented as illustrative examples only and may vary in other embodiments. For example, although only a single validator device 104 is shown in this embodiment, other embodiments may include multiple validator devices, such as in an arrangement in which other ZKP oracle nodes 110 operate as corresponding validator devices. Furthermore, one or more of the TLS servers 106 may each be configured to control access to multiple of the protected data sources 108. Numerous other distributed oracle arrangements are possible.

[0031] The validator device 104 includes a three-way handshake module 112, a post-handshake interaction module 114, and a proof verification module 116. These modules implement different protocols of the distributed oracle protocol, also referred to herein as the DECO protocol, as described in more detail below.

[0032] In this embodiment, the verifier device 104 further includes a processor 120, a memory 122, and a network interface 124. It is assumed that the processor 120 is operatively coupled to the memory 122 and the network interface 124 via simplified illustrative interconnects shown in the figures.

[0033] Processor 120 can be any combination including, for example, a microprocessor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a central processing unit (CPU), a graphics processing unit (GPU), an arithmetic logic unit (ALU), a digital signal processor (DSP), or another similar processing device component, as well as other types and arrangements of processing circuitry systems. At least a portion of the functionality of a distributed oracle provided by a given processing device as disclosed herein can be implemented using such a circuitry system.

[0034] Memory 122 stores software program code for execution by processor 120 when implementing a portion of the functionality of the processing device. For example, the program code stored in memory 122 can be used to implement at least a portion of the functionality of modules 112, 114, and 116.

[0035] A given memory that stores such program code for execution by a corresponding processor is an example of the contents of a processor-readable storage medium having program code embodied therein, and may include, in any combination, electronic memory such as SRAM, DRAM or other types of random access memory, read-only memory (ROM), flash memory, magnetic memory, optical memory or any combination of other types of storage devices.

[0036] Articles of manufacture including such processor-readable storage media are considered embodiments of the present invention. As used herein, the term "article of manufacture" should be understood to mean that it does not contain transient propagation signals.

[0037] In other embodiments, other types of computer program products, including processor-readable storage media, may be implemented.

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

[0039] Network interface 124 is configured to allow verifier device 104 to communicate with other system components via network 105, and may include one or more conventional transceivers.

[0040] In operation, in the illustrative embodiment, the verifier device 104 is configured to participate in a three-way handshake protocol with a given one of the client devices 102 (e.g., client device 102-1) and a given one of the TLS servers 106. This participation is illustratively controlled by the three-way handshake module 112 of the verifier device 104. In conjunction with the execution of the three-way handshake protocol, the verifier device 104 and the client device 102-1 obtain a corresponding sharing of session keys for a secure session with the given TLS server. The secure session illustratively includes a TLS session.

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

[0042] Verifier device 104 verifies, at least in part, the correctness of at least one representation of data obtained by client device 102-1 from a given TLS server as part of a secure session, based on submissions and additional information. This verification is illustratively performed under the control of proof verification module 116.

[0043] In some embodiments, the verifier device 104 is further configured to initiate one or more automated actions in response to verification of the correctness of at least one representation 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.

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

[0045] As another example, submissions related to a secure session may include submissions of a prover key established by client device 102-1 in conjunction with a three-way handshake protocol but previously inaccessible to verifier device 104. In other embodiments, other types of submissions may be used.

[0046] In some embodiments, additional information released to client device 102-1 in response to receiving a submission includes a validator key established by validator device 104 in conjunction with a three-way handshake protocol but previously inaccessible to client device 102-1.

[0047] In other embodiments, the verifier device 104 is further configured to operate as a proxy for the client device 102-1 in conjunction with the interaction between the client device 102-1 and the given TLS server, such that the verifier device 104 automatically obtains the ciphertext exchanged between the client device 102-1 and the given TLS server as part of the secure session via the verifier device 104 operating as a proxy. This embodiment is referred to herein as a "proxy mode" arrangement.

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

[0049] For example, one of the statements may illustratively include a substring of query response data selectively revealed by client device 102-1 from a given TLS server as part of a secure session.

[0050] As another example, one of the statements is illustratively configured to provide context integrity by utilizing a multi-stage resolution protocol, in which query response data obtained by client device 102-1 from a given TLS server as part of a secure session is preprocessed by client device 102-1 to produce reduced data, which is then parsed by client device 102-1 in conjunction with the production of a given statement to be sent by client device 102-1 to verifier device 104.

[0051] In other embodiments, a wide variety of other types of statements may be used to represent data obtained by client device 102-1 from a given TLS server as part of a secure session.

[0052] In some embodiments, in conjunction with a three-way handshake protocol, client device 102-1 and verifier device 104 jointly establish one or more shared session keys with a given TLS server, wherein client device 102-1 has a first shared key of a given one of the one or more shared session keys, verifier device 104 has a second shared key of the given shared session key, and the given TLS server has a composite session key combining the first shared key and the second shared key.

[0053] Alternatively, in conjunction with a three-way handshake protocol, client device 102-1 receives an encryption key from a given TLS server that is inaccessible to verifier device 104.

[0054] In some embodiments, the verifier device 104 and the client device 102-1 cooperate using a corresponding sharing of their session keys with a given TLS server to generate a query provided by the client device 102-1 to the given TLS server, requesting the given TLS server to send data to the client device 102-1.

[0055] The verifier device 104 and the client device 102-1 can cooperate using the corresponding sharing of their session keys with the given TLS server's secure session to verify the response provided to the client device 102-1 by the given TLS server in response to a query.

[0056] In some embodiments, client device 102-1 and verifier device 104 establish corresponding provers and verifier keys in conjunction with a three-way handshake protocol. In this embodiment, verifying the correctness of at least one representation of data obtained by client device 102-1 from a given TLS server as part of a secure session illustratively includes verifying the 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) the prover key established by client device 102-1 in conjunction with the three-way handshake protocol; (ii) the verifier key established by verifier device 104 in conjunction with the three-way handshake protocol; and (iii) secret information of client device 102-1, such as a password or cipher.

[0057] In some embodiments, verifying the correctness of at least one representation of data obtained by 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 client device 102-1 verifying the correctness of at least one representation of the data. The term “ciphertext” as used in this context and elsewhere herein is intended to be understood broadly and should not be construed as requiring the use of any particular cryptographic protocol.

[0058] It should be understood that Figure 1 The specific arrangement of the components and other system elements shown and their associated processing operations as described above are presented only as illustrative examples, and numerous alternative embodiments are possible.

[0059] For example, although the validator device 104 in system 100 is illustratively shown as a single processing device including a processor coupled to memory, in other embodiments, the validator device may include a distributed validator device, wherein the functionality of the validator device 104 is distributed across multiple different processing devices. In such embodiments, the role of the validator in the various protocols disclosed herein may be distributed across multiple different parties performing multi-party protocols, each of which is associated with a different one of the multiple processing devices of the distributed validator device. Therefore, the term "device" as used herein is intended to be understood broadly to cover at least one processing device including a processor coupled to memory, and thus to cover multiple such processing devices as in the case of a distributed validator device.

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

[0061] In this embodiment, the process illustratively includes steps 200 to 208. As described above, it is assumed that at least part of these steps are performed by a verifier device 104 that interacts with one of the client devices 102 and further relates to one of the TLS servers 106. These components in Figure 2 In the context of the process, they are also referred to as verifier, prover, and server, respectively.

[0062] In step 200, the verifier participates in a three-way handshake protocol with the client and server, where the client acts as the verifier.

[0063] In step 202, in conjunction with the three-way handshake protocol, the verifier and the certifier obtain the corresponding shared session key for the secure session with the server.

[0064] In step 204, the verifier receives a submission related to the secure session of the server from the prover.

[0065] In step 206, in response to receiving a submission, the validator releases additional information to the prover related to a secure session that was previously inaccessible to the prover.

[0066] In step 208, the verifier verifies, at least in part, the correctness of at least one representation of the data obtained by the verifier from the server as part of a secure session, based on the submission and additional information.

[0067] Numerous other technologies can be used in conjunction with the distributed oracle implementations disclosed herein.

[0068] Therefore, combining Figure 2 The specific processing operations and other functionalities described in the flowcharts are presented as illustrative examples only and should not be construed as limiting the scope of the invention in any way. Alternative embodiments may use other types of processing operations involving validator devices, prover devices, and server devices. For example, the order of process steps may vary in other embodiments, or certain steps may be performed simultaneously with each other rather than sequentially. Furthermore, multiple instances of the process may be performed in parallel with each other within system 100 for different sets of corresponding provers, validators, and server devices. Thus, system 100 can implement a large number of distributed oracles simultaneously using the techniques disclosed herein.

[0069] Reference Figures 3 to 14 Additional aspects of the illustrative embodiments are described.

[0070] The widespread deployment of TLS allows users to access private data via a channel with end-to-end confidentiality and integrity. However, what users cannot easily do in conventional practice is to prove the origin of this data to third parties—that is, that it truly comes from a specific website. Existing methods introduce undesirable trust assumptions or require server-side modifications.

[0071] As a result, users' private data is locked at its point of origin. Users cannot export their data to other applications in an integrity-protected manner without the help and permission of the current data holder.

[0072] The illustrative embodiments described herein provide a technique called DECO (short for Distributed Oracle) to address these and other problems. DECO allows a user to prove that a piece of data accessed via TLS originates from a specific website, and optionally proves statements about such data with zero knowledge, thereby maintaining the data's own secrecy. Advantageously, the DECO in the illustrative embodiments can be implemented without requiring trusted hardware or server-side modifications.

[0073] DECOs release data from centralized network service repositories, making it accessible to a wide range of applications. To demonstrate the power of DECOs, we implement three applications that would be difficult to achieve without them: private financial instruments using smart contracts, converting traditional credentials into anonymous credentials, and verifiable claims against price discrimination.

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

[0075] As indicated above, TLS is a robust and widely deployed protocol that allows users to access network data via a confidential, integrity-protected channel. However, TLS has a significant limitation: it does not allow users to prove to third parties that a piece of data they have accessed truly originated from a specific website. Therefore, data use is often limited to its point of origin, thus reducing the user's data portability, a right recognized by recent regulations such as the GDPR.

[0076] Specifically, when a user accesses data online via TLS, she cannot securely export it without the assistance (and therefore permission) of the current data holder. Thus, a large amount of private data is intentionally or unintentionally locked in the "deep web," a portion of the network that is not publicly accessible.

[0077] To better understand the problem, consider the scenario where Alice wants to prove to Bob that she is over 18. Currently, age verification services typically require users to upload their IDs and detailed personal information, raising privacy concerns. However, various websites, such as company payment records or DMV websites, in principle store and service-verified dates of birth. Alice could send a screenshot of her date of birth from this site, but this is easily forged. Furthermore, even if the screenshot could be proven authentic in some way, it would still leak information (revealing her exact date of birth), not just that she is over 18.

[0078] Oracles were originally proposed to prove the provenance of online data to smart contracts, serving as a step towards exporting TLS-protected data to other systems with provenance and integrity guarantees. However, existing schemes have significant technical limitations. They either only work with deprecated TLS versions and do not provide privacy from the oracle (e.g., TLSNotary), or rely on trusted hardware (e.g., Town Crier), for which various attacks have recently emerged. Another category of oracle schemes assumes server-side collaboration, delegating the installation of TLS extensions or changes to application-layer logic to the server. Server-facilitated oracle schemes suffer from two fundamental problems. First, they break traditional compatibility, creating a significant barrier to wider adoption. Furthermore, this solution only provides conditional exportability because the web server has unique sole discretion in determining which data can be exported and can arbitrarily censor export attempts. Mechanisms that allow users to export any data they have access to would enable many applications that are currently impossible.

[0079] To address the above issues, the illustrative embodiments disclosed herein provide an arrangement called DECO, a distributed oracle for TLS. Unlike oracle schemes that require support from each website, DECO is illustratively for any website whose origin is unknown and which supports running standard TLS. Unlike solutions that rely on website participation, DECO does not require server-side cooperation. Therefore, a single instance of DECO allows anyone to become an oracle for any website.

[0080] DECO enables a wealth of internet data to be accessed with authenticity and privacy guarantees by a wide range of applications, including those without internet access, such as smart contracts. DECO can fundamentally change today's online data dissemination model by providing options for private data delivery to third parties or public release. This technological capability highlights potential future legal and regulatory challenges, but also anticipates the creation and delivery of compelling new services. Importantly, unlike some alternatives, DECO does not require trusted hardware.

[0081] In some embodiments, at a higher level, the prover submits a block of data D and proves to the verifier that D comes from the TLS server. And optionally submit statements about D. D Referring again to examples proving age, state π. D It can be asserted that "D = y / m / d is Alice's birth date and the current date - D is at least 18 years".

[0082] Informally, DECO implements authenticity—the verifier only verifies the truth of a statement about D and that D was actually obtained from the TLS server. It is only confirmed upon acquisition. DECO also provides privacy because the validator only learns to state π. D From Some of the D values ​​obtained are valid.

[0083] Designing a DECO with the required security and practicality while using traditional TLS-compatible primitives presents several significant technical challenges. One challenge stems from the fact that TLS generates symmetric encryption and authentication keys shared by the client (e.g., the prover in the DECO) and the web server. Therefore, in the sense that data is signed with a valid authentication key, a client can forge arbitrary TLS session data.

[0084] To address this challenge, DECO introduces a novel three-way handshake protocol among the prover, validator, and web server. This protocol creates an unforgeable submission of a block of TLS session data D from the prover to the validator. The validator can verify that D genuinely originates from the TLS server. From the prover's perspective, the three-way handshake maintains TLS security even in the presence of a malicious validator.

[0085] Efficient Selective Openness. After a submission to D, the prover proves a statement about the submission. While theoretically any statement can be supported, we optimize for perhaps the most popular applications—revealing only a substring of the validator's response. We call this selective openness. Fine-grained selective openness allows users to hide sensitive information and reduces the input length for subsequent proofs.

[0086] Inadequate solutions would involve expensive verifiable decryption of TLS records using generalized zero-knowledge proofs (ZKPs), but the illustrative embodiments in this paper achieve magnitude-level efficiency improvements by leveraging the TLS record structure. For example, a direct implementation of verifiable decryption of a TLS record would involve the correct execution of a circuit using 1024 AES calls with zero-knowledge proofs, while the illustrative embodiments in this paper achieve the same result with only 3 AES calls by utilizing the MAC-then-encrypt structure of CBC-HMAC.

[0087] Contextual integrity. Selective openness allows the prover to reveal only a substring D′ of the server's response D. However, a substring can mean different things depending on when it appears, and a malicious prover can cheat by taking things out of context. Therefore, we need not only to prove that D′ appears in D, but also that it appears in the expected context; that is, D′ has contextual integrity relative to D. (Note that this is different from "contextual integrity" in privacy theory.)

[0088] If the session content is structured and parsable, then context integrity attacks can be prevented. Fortunately, most network data takes this form (e.g., as JavaScript Object Notation (JSON) or Hypertext Markup Language (HTML)). The general solution is to parse the entire session and prove that the revealed portion belongs to the necessary branch of the parse tree. However, under certain constraints that network data typically satisfies, parsing the entire session is not necessary. Some embodiments disclosed herein provide novel two-phase parsing schemes in which the prover preprocesses the session content and parses only the typically much smaller result. We draw from the interpretation of equivalents of programs used in programming language theory to construct a formal framework for the security of two-phase parsing schemes. The illustrative embodiments disclosed herein provide several practical implementations for specific syntaxes. Our definitions and constructions are also generalized to other oracles. For example, a general form that prevents content hiding attacks.

[0089] Regarding the implementation and evaluation of the illustrative embodiments, we designed and implemented DECO as a complete end-to-end system. To demonstrate the effectiveness of the system, we implemented three applications: 1) maintaining the confidentiality of financial instruments using smart contracts;

[0090] 2) Convert traditional credentials into anonymous credentials; and 3) Verifiable claims against price discrimination.

[0091] Our experiments with these applications demonstrate that DECO is highly effective. For example, for TLS 1.2 in a WAN configuration, the uptime is 2.85 seconds for the three-way handshake and 2.52 seconds for 2PC query execution. For the applications described above, generating zero-knowledge proofs takes approximately 3 to 13 seconds. More details are provided elsewhere in this paper.

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

[0093] We also describe in detail below a wide range of statements for TLS records that can be effectively proven in zero-knowledge using DECO. Such statements allow users to open only substrings of session data submissions. The optimized implementation offers substantial efficiency improvements over general-purpose ZKP.

[0094] Regarding context integrity attacks and mitigations, we identify a new class of context integrity attacks common to privacy-preserving oracles, and we describe our mitigation approach involving a novel and efficient two-phase resolution scheme.

[0095] Transport Layer Security (TLS)

[0096] We now provide some background on the TLS handshake and record protocol, which DECO builds upon in the illustrative embodiment.

[0097] TLS is a set of protocols that provide privacy and data integrity between two communicating applications. Broadly speaking, it consists of two protocols: a handshake protocol, which uses asymmetric cryptography to establish a session, thereby establishing shared client and server keys for the next protocol; and a record protocol, in which symmetric cryptography is used to protect transmitted data with confidentiality and integrity.

[0098] Handshake. In the handshake protocol, the server and client first agree on a set of cryptographic algorithms (also called a set of cryptographic procedures). They then authenticate each other (client authentication is optional), and finally securely compute a shared secret to be used in subsequent record protocols.

[0099] In the illustrative embodiment, DECO utilizes an elliptic curve Diffie-Hellman (DH) key exchange (ECDHE) with a transient secret, but this is by way of example and not a limitation.

[0100] Record Protocol. To transmit application layer data (e.g., HTTP messages) in TLS, the record protocol first segments the application data D into fixed-size plaintext records D = (D1, ..., D2). n Each record is typically padded into multiple blocks (e.g., 128 bits). The record protocol then optionally compresses the data, applies a MAC, encrypts it, and transmits the result. Received data is decrypted, verified, decompressed, reassembled, and then delivered to higher-level protocols. Specific cryptographic operations depend on the negotiated cipher suite. DECO supports two common modes of Advanced Encryption Standard (AES) ciphers: CBC-HMAC and GCM, where CBC-HMAC stands for Cipher Block Chaining-based Hash Message Authentication Code, and GCM stands for Galois / Counter Mode. Additional details regarding these and other aspects of TLS can be found, for example, in T. Dierks and E. Rescorla's "Transport Layer Security (TLS) Protocol Version 1.2," RFC 5246, 2008, which is incorporated herein by reference. Similarly, other protocols may be used in other embodiments.

[0101] Differences between TLS 1.2 and 1.3. In some embodiments of this paper, we focus on TLS 1.2, and later describe how our techniques can be generalized to TLS 1.3. Here we briefly note the main differences between the two TLS versions. TLS 1.3 removes support for traditional non-AEAD ciphers. The handshake process has also been restructured. All handshake messages after ServerHello are now encrypted. Finally, different key-derived functions are used. Additional details can be found in E. Rescorla's "Transport Layer Security (TLS) Protocol Version 1.3" RFC 8446, 2018, which is incorporated herein by reference.

[0102] Multi-party calculation

[0103] Consider n-squared groups Each of them keeps some secrets. i Secure multi-party computation (MPC) allows them to jointly compute f(s) without leaking any information other than the output of f. i ,…,s n ),Right now, For s j≠i Completely unaware. The security of MPC protocols typically considers an adversary who compromises t players and attempts to learn the private information of honest players. Two-way computation (2PC) refers to the special case where n=2 and t=1.

[0104] There are two general approaches to the 2PC protocol. The scrambling circuit protocol encodes f as a boolean circuit, which is best suited for bitwise operations (e.g., SHA-256). Other protocols utilize threshold secret sharing and are best suited for arithmetic operations. However, in some embodiments, the function we use to compute with 2PC involves both bitwise and arithmetic operations. We separate this into two components, using an optimized scrambling circuit protocol for bitwise operations and a secret-sharing-based MtA protocol for arithmetic operations. Additional details regarding the instance-optimized scrambling circuit protocol used in the illustrative embodiments can be found in "Authenticated Garbling and Efficient Maliciously Secure Two-Party Computation" by Xiao Wang, Samuel Ranellucci, and Jonathan Katz at ACM CCS, 2017, which is incorporated herein by reference. Additional details regarding the secret-sharing-based MtA protocol used in the illustrative embodiments can be found in Rosario Gennaro and Steven Goldfeder's "Fast multiparty threshold ECDSA with fast trustless setup" in ACM CCS, 2018, which is incorporated herein by reference. These are merely examples, and other types of protocols may be used in other embodiments.

[0105] We now state the problems addressed by illustrative embodiments of DECO and present a high-level overview of its architecture.

[0106] Problem Statement: Distributed Oracles

[0107] The illustrative embodiments in this document provide protocols for constructing "oracles" (i.e., entities that can prove the origin and nature of online data). The goal is to enable provers... To the validator Prove that a piece of data comes from a specific website And statements about such data can be arbitrarily proven with zero knowledge, thus keeping the data itself secret. Access to the data may require... Private input (e.g., password) and such private information should also be obtained from Keep it a secret.

[0108] Our illustrative embodiments focus on servers running TLS, a widely deployed suite of security protocols on the Internet. However, TLS alone does not prove the origin of data. While TLS uses public-key signatures for authentication, it uses 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, knowing this symmetric key... Unable to provide third parties with evidence of statements regarding cryptographically authenticated TLS data.

[0109] A web server itself can assume the role of an oracle, for example, by simply signing the data. However, server-facilitated oracles not only incur high adoption costs but also disadvantage users: the web server can impose arbitrary constraints on the oracle's capabilities. We are interested in schemes where anyone can prove the origin of any data they can access without relying on a single central point of control (e.g., the web server providing the data).

[0110] In our illustrative embodiments, we address these and other attacks by introducing something we refer to herein as a “decentralized oracle” that does not rely on trusted hardware or collaboration from a web server. This poses a significantly greater challenge than previous oracles because it hinders solutions that require servers to modify their code, deploy new software, or utilize prediction markets, while simultaneously going beyond these previous approaches by supporting arbitrary assertions on the data.

[0111] Authentication Data Feeds for Smart Contracts. A key application of the illustrative embodiments disclosed herein is the construction of Authentication Data Feeds (ADFs) for smart contracts, i.e., data with verifiable provenance and correctness. A wide variety of other applications are advantageously supported by the techniques disclosed herein.

[0112] In the context of ADF, since smart contracts cannot participate in the 2PC protocol, they must rely on oracle nodes to represent them. Participation. Therefore, in some embodiments, we deploy DECO in a decentralized oracle network, where a set of independently operating oracles are available for use by smart contracts. It should be noted that the oracles running DECO are trusted only for integrity, not for privacy. Smart contracts can further hedge against integrity failures by querying multiple oracles and requiring, for example, most protocols. We emphasize that DECO's privacy is protected even if all oracles are compromised. Thus, DECO enables users to provide an ADF derived from private data to smart contracts while hiding private data from the oracles.

[0113] Symbols and Definitions

[0114] In some embodiments, we use To refer to the proof device, using To refer to the validator and use To refer to the TLS server. We use bold letters (e.g., M) to refer to vectors and use M. i Let it refer to the i-th element in M.

[0115] We use such Figure 3 The ideal functionality described in the document To model the fundamental properties of oracles. Each message runs independently in parallel, and all messages are tagged with a unique session ID, referred to as sid. Additional or alternative oracle properties may be used in other embodiments.

[0116] like Figure 3 As indicated in the document, in this embodiment, Accept from The secret parameter θ s (e.g., password), query template, and from The statement Stmt. The query template is for retrieving... The secret θ s And the function that returns the complete query contains... The specified public parameters. The instance query template will be Query(θ) s = "GOOG's stock price on January 1, 2020, where API key = θ" s "Proof device" It can be proven later that the query sent to the server is well-formed (i.e., constructed from the template) without revealing the secret. Stmt is stated as... A function to evaluate the server's response. Following the previous example, since the response R is a number, the following statement will compare it with a threshold: Stmt(R) = "R > $1,000".

[0117] exist Acknowledge the query template and statement (by sending "OK" and θ) s )after, Retrieve data from queries built from templates. The response R. We assume an honest server, therefore R is the real data. Send Stmt(R) and data source to

[0118] We are interested in this embodiment of a distributed oracle that does not require any server-side modifications or collaboration, namely, It follows the unmodified TLS protocol. More specifically, the decentralized oracle protocol used for TLS is a three-party protocol. Enables 1) Prot to achieve And 2) It is standard TLS, possibly along with application layer protocols.

[0119] Adversary Model and Security Properties. In the illustrative embodiments, we consider static malicious network adversaries. The injured party may arbitrarily deviate from the agreement and appeal to the relevant authorities. Reveal its status. As a cyber adversary, from The message length is learned because TLS does not hide the length. We assume... and According to The application layer protocol to be run selects and contracts appropriate queries (e.g., they should be idempotent for most applications) and statements.

[0120] For a given query Depend on Refers to the server's honest response. We require when or Maintain safety in case of damage. Functionality This reflects the following security guarantees:

[0121] • Proofer integrity: Malicious Unable to forge the source of the content, she also could not make... Accepts invalid queries or incorrectly responds to valid queries. Specifically, if the validator input is (Query, Stmt) and the output is... So It must have already been included in the TLS session. Send to Thus, a response is received. This makes b = Stmt(R).

[0122] • Validator integrity. Maliciously Unable to make An incorrect response was received. Specifically, if... If the output is (Q, R), then R must be a value from the server. Submitted query The response, that is,

[0123] Privacy: Malicious Learning only public information And the evaluation of Stmt(R).

[0124] The Strawman Protocol

[0125] Our illustrative embodiments focus on two widely used, representative TLS cipher sets: CBC-HMAC and AES-GCM. Our techniques are also generalized to other ciphers (e.g., Chacha20-Poly1305, etc.). We initially use CBC-HMAC to illustrate certain embodiments, and later describe techniques for AES-GCM.

[0126] TLS uses a separate key for each direction of communication. Unless explicitly specified, we do not distinguish between the two and use k. Enc and k MAC Refers to the session key used in both directions.

[0127] In presenting illustrative embodiments of DECO, we begin with the Scarecrow Protocol and gradually build it up to a complete protocol.

[0128] accomplish Between The Scarecrow Agreement is as follows. Query server And all messages sent to the server and received from the server are recorded separately in and In the middle. Assuming. and (k) MAC ,k Enc ) is the session key.

[0129] She then used zero-knowledge proof 1) for each Decrypt to R i ‖σ i 1) Plaintext records and MAC tags; 2) Used for R i Each MAC tag σ i For k MAC Perform verification; and 3) the required statement evaluates b to the response (i.e., b = Stmt(R)). Use standard notation. calculate

[0130]

[0131] ∧Verification(k) MAc ,σ i ,R i )=1∧Stmt(R)=b}.

[0132] She also proved well formed as For example, in proving p q Similar to that in China, and will Send to

[0133] exist Under the condition of a true transcription of a TLS session, the prover integrity properties appear to be preserved. Intuitively, the CBC-HMAC ciphertext is bound to the underlying plaintext, therefore... This can be considered a secure submission of session data. In other words, given... Only accessible for unique messages (i.e., decryption and MAC checking). Binding properties prevent... Open to different messages except for the initial session with the server.

[0134] Unfortunately, this intuition is flawed. The scarecrow agreement fails completely because it cannot guarantee... The authenticity. Proof device. She has a session key, and therefore she can contain... Encryption of any message in the system.

[0135] Furthermore, zero-knowledge proofs The proposed protocol would require decrypting and hashing the entire transcription, which would be prohibitively expensive. To make the protocol truly feasible, we need to significantly reduce the cost.

[0136] DECO Overview

[0137] The key failure of the scarecrow method mentioned above lies in The session key is learned before she submits it to the session. In the illustrative embodiment of DECO, from Withhold the MAC key until she submits it.

[0138] With server TLS sessions between nodes must still provide confidentiality and integrity. Furthermore, the protocol must not degrade performance below TLS requirements (e.g., by triggering timeouts).

[0139] Figure 4 An example DECO implementation scheme including a server device, a prover device, and a verifier device is shown in the illustrative embodiment. In this embodiment, the DECO is implemented as a three-phase protocol. The first phase is in which the prover... Validator and TLS server Based on and A novel three-way handshake protocol for secretly sharing session keys. Following the handshake is the query execution phase, during which... Follows the standard TLS protocol but in the presence of... Access the server with the help of [unclear - possibly "information"]. After submitting the query and response, Reveal her key sharing. Finally, Prove the statements about the response during the proof generation phase.

[0140] A three-way handshake. Basically. and They jointly act as TLS clients. Their negotiation takes the form of a secret sharing mechanism. The shared session key. We emphasize that this phase (similar to the rest of the DECO) is crucial for... It is completely transparent, thus requiring no server-side modifications.

[0141] For the CBC-HMAC cipher suite, at the end of the three-way handshake... and Receive separately and at the same time take over Like a standard handshake, and Both obtain the encryption key k Enc .

[0142] The three-way handshake can ensure that the aforementioned session data submission is unforgeable as follows. At the end of the session, First submit to The conversation in the middle, as mentioned above, continues... Revealing her sharing from From this perspective, the three-way handshake protocol ensures that the new MAC key (for each direction) is used in every session, regardless of the impact of a potentially malicious prover, and the key pair... It remains unknown until she submits it. Without knowledge of the MAC key, Session data cannot be forged or tampered with before it is committed. The unforgeability of session data commits in DECO therefore reduces the unforgeability of the MAC scheme used in TLS.

[0143] It can similarly support other cryptographic groups, such as GCM. In GCM, a single key (for each direction) is used for both encryption and MAC. The handshake protocol is similar in... and They secretly share a key. The handshake protocol used for GCM is described in more detail elsewhere in this document.

[0144] Query execution. Since the session key is secretly shared, as mentioned, therefore... and Execute the interactive protocol to construct a TLS message that encrypts the query. The message is then sent to the standard TLS client. For CBC-HMAC, the MAC tag of the query is calculated, while for GCM, authentication encryption is performed. It should be noted that the query... For private use and should not be disclosed to General 2PC would be expensive for larger queries, so we instead introduced a custom 2PC protocol that is more efficient than the general solution, as described elsewhere in this paper.

[0145] As explained earlier, Received Key sharing is submitted to session data beforehand. This makes the submission unforgeable. Next... The integrity of the response can be verified, and the statements made about it can be proven, as will be described below.

[0146] Proof is generated using an unforgeable submission, if Fully open submissions (That is, reveal the encryption key), then This can be easily verified by examining the decrypted MAC address. The authenticity of.

[0147] However, revealing the use of The encryption key will compromise privacy: it will reveal in and All session data exchanged between them. Theoretically, It can be changed to zero-knowledge proof (i.e., without revealing the encryption key). Any statement on Stmt. However, general zero-knowledge proof techniques would be excessively expensive for many of the inherent options of Stmt.

[0148] DECO instead introduces two techniques to support efficient proofs of statements across a broad range of general categories, referred to in this paper as the "selective openness" technique for TLS session transcription. Selective openness involves... Revealing or revising (i.e., cutting off) substrings, thereby providing... Hide the substring.

[0149] Figure 5 A simplified JSON bank statement by user Bob, acting as a prover, is presented as an illustrative example. This example will be used to demonstrate selective openness and context integrity attacks. Assume Bob... Want to Revealing his checking account balance. Revealing the decryption key used for his TLS session would be undesirable: it would also reveal the entire statement, including his transaction. Alternatively, using the techniques disclosed herein, Bob could efficiently reveal only the substrings in lines 5 through 7. Alternatively, if he didn't mind revealing his savings account balance, he could revise his transaction after line 7.

[0150] Two selective open modes (revealing and revising substrings) are useful privacy-preserving mechanisms. They can also serve as preprocessing for subsequent zero-knowledge proofs. For example, Bob might want to prove he has an account with a balance greater than $1000 without revealing the actual balance. He would then use a zero-knowledge proof on the assertion ("balance > $1000") on a substring containing his checking account balance.

[0151] However, selective openness alone is insufficient for many applications. This is because the context of a substring influences its meaning. Without something we call context integrity, It is possible to cheat and reveal the error as a manifestation of... Proof of a substring in a statement. For example, Bob might not have a balance higher than $1000. However, after reviewing his bank statement, he could send a message to customer service in the same TLS session with the substring "balance": $5000, and then review his pending message (in the form of a reflection attack). He could then reveal this substring to deceive...

[0152] The destination of the proof device supply Various input cleansing heuristics (e.g., truncation of session transcription) can potentially prevent some of these attacks, but like other forms of web application input cleansing, it is vulnerable and susceptible to attack.

[0153] Alternatively, we introduce a rigorous technique to explicitly but covertly parse session data. We call this technique "zero-knowledge two-stage parsing." Based on this technique, Local parsing in the first stage And then, with zero knowledge... Prove the statement regarding the constraints on the resulting substring. For example, in our bank instance, if the bank-supplied key value store is always escaped with the distinguishing character λ, then Bob can pass through the key value store via local parsing and... The preceding substring "balance" is revealed to be λ: $5000, which is extracted to prove the correct balance. It can be demonstrated that for very common categories of network API syntax (unique keys), this two-phase approach produces proofs far more efficiently than more general techniques.

[0154] Figure 6 A more detailed example implementation of the DECO protocol described above is presented. In this embodiment, the DECO protocol includes a three-way handshake phase, followed by a 2PC protocol for querying the execution phase, and a proof generation phase. Each of these phases will be described in more detail below. It should be understood that the specific details of this embodiment (as with 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.

[0155] Three-way handshake

[0156] In some embodiments, the goal of the three-way handshake (3P-HS) is to... A completely transparent approach in the proof With validator Secret sharing between servers The session key used in the TLS session. We first focus on explaining CBC-HMAC, and then adapt the protocol to support GCM.

[0157] Figure 7 The formal specification of the three-way handshake protocol is shown in the illustrative embodiment.

[0158] Figure 8 The ECtF protocol, as an example of a three-way handshake protocol, is shown in some embodiments.

[0159] Similarly, the specific details of these protocols are merely examples and are not intended to limit the scope in any way. For instance, in other embodiments, a wide variety of other types of three-way handshake protocols involving provers, validators, and servers may be used. Therefore, the term "three-way handshake protocol" as used herein is intended to be understood broadly.

[0160] Like the standard TLS handshake, 3P-HS involves two steps: First, and Calculate the secret shared with the server via a TLS-compatible key exchange protocol. The addition and sharing. ECDHE is recommended and focused here, but other techniques can be used for computation sharing; secondly, and The secret-shared session key is derived by securely evaluating the TLS-PRF using its Z-shared value as input, where PRF stands for pseudo-random function. We provide a textual description below, so a formal specification is not required for understanding.

[0161] Step 1: Key Exchange. Assume... The term refers to the EC group used in ECDHE, and G refers to its generator.

[0162] Proof device By using a regular TLS handshake request and a random temporary value r c Send to (In the ClientHello message) the handshake is initiated. From... Received certificate, server temporary value r s and signed ephemeral DH public key (In the Server-Hello and ServerKeyExchange messages) after, Check the certificate and signature and forward it to After performing the same check For secrets V Sampling and using the DH public key Y V =s V ·G's part was sent to It then went on to another secret. P Sampling and combining the DH public key Y P =s P ·G+Y V Send to

[0163] Due to the server Running standard TLS, so in (and ) calculate its Z-share as Z P =s P ·Y S (and Z) V =s V ·Y S )hour, The DH secret will be calculated. Note that Z = Z P +Z V , where + represents Group operations. Assuming the discrete logarithm problem is difficult in the chosen group, then Z is unknown for either side.

[0164] Step 2: Key Export. Now and An additive sharing of Z (in EC point form) has been established, which derives the session key by evaluating the TLS-PRF with the key at the x coordinate of Z.

[0165] The technical challenge here is to coordinate arithmetic operations in 2PC (i.e., Addition in the context of binary operations (i.e., TLS-PRF). Boolean circuits are not well-suited for arithmetic over large domains. As a specific estimate, EC-point addition, which only produces the x-coordinate, involves four subtractions, one modular inversion, and two modular multiplications. Estimates of the AND complexity based on a highly optimized circuit result in over 900,000 AND gates used only for subtraction, multiplication, and modular reduction—not even including inversions—which would require running an extended Euclidean algorithm within the circuit.

[0166] This is attributed to the excessive cost of adding EC points to Boolean circuits. and Used in demonstration Figure 8 The ECtF protocol in China will The summation and sharing of EC points in the middle is converted to its value in the middle. The x-coordinate in the equation. Then the Boolean circuit only involves the x-coordinate in the equation. Add two numbers, which can be done using only a ~3|p|AND gate, which is a ~768AND gate in our implementation, where p is 256 bits.

[0167] Use ECTF's shared conversion. The ECTF protocol will... Shared conversion in The sharing within. The input to the ECtF protocol is two EC points. Labeled as P i =(x i y i Assume (x) s ,y s ) = P1★P2, where ★ represents the EC group operation, then the output of the protocol is Make α+β=x s Specifically, for the curve we are considering, x s -λ 2 -x1-x2, where λ=(y2-y1) / (x2-x1). y can be calculated similarly. s The sharing, but we omit the calculations mentioned, because TLS only uses x s .

[0168] ECtF uses the Multiply-Add (MtA) shared transformation protocol as its building blocks. We use α, β := MtA(α, b) to refer to the MtA operation between Alice and Bob with inputs α and b, respectively. At the end of the operation, Alice and Bob receive α and β such that a·b = α + β. The protocol can be generalized to handle vector inputs without increasing communication complexity. That is, for vector inputs... If α, β: = MtA (α, b), then (α, b) = α + β.

[0169] Now we describe the protocol of ECtF. ECtF has two main components. Assume that [α] refers to two shares of α, i.e., [α] = (α1, α2), such that party i has α for i ∈ {1, 2} i , while α = α1 + α2. The first component is share inversion: given [α], compute [α -1 . This can be done as follows: Party i samples a random value r i and performs MtA to compute δ1, δ2 := MtA((α1, r1), (r2, α2)). Note that δ1 + δ2 = α1·r2 + α2·r1. Party i publishes v i = δ i + α i ·r1, and thus both parties learn v = v1 + v2. Finally, party i outputs β i = r i ·v -1 . The protocol computes the correct share of α -1 because β1 + β2 = α -1 . Additionally, the protocol does not leak α to any party assuming MtA is secure. In fact, the view of party i consists of (α1 + α2)(r1 + r1), which is uniformly random because r i is uniformly random.

[0170] The second component is share multiplication: compute [αb], given [α], [b]. [αb] can be computed using MtA as follows: The parties perform MtA to compute α1, α2 such that α1 + α2 = α1·b2 + α2·b2. Then, party i outputs mi = α i + α i ·y i . The security and correctness of the protocol can be argued similarly as above.

[0171] Security evaluation of TLS-PRF. In the case where the x - coordinate of Z in ECtF has been computed as a share (the so - called pre - master secret in TLS), and evaluate 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 circuit with a total AND complexity of 779,213.

[0172] Adaptation to support GCM. For GCM, a single key (for each direction) is used for both encryption and MAC. Adapting the above protocol to support GCM in TLS1.2 is straightforward. The first step remains the same, while the output of the second step needs to be truncated because the GCM key is shorter.

[0173] Adapting to TLS 1.3. To support TLS 1.3, the 3P-HS protocol must be adapted to the new handshake procedure and different key derivation circuitry. It's worth noting that all handshake messages after ServerHello are now encrypted. An immature strategy would involve decrypting these messages in a 2PC, which would be expensive given the typically large certificates. However, thanks to the key independence nature of TLS 1.3, we can construct a 3P-HS protocol with similar complexity to TLS 1.2, as described elsewhere in this document.

[0174] Query execution

[0175] After the handshake, the proof device Her query Send to the server that is a standard TLS client. But with the help of the validator With the help of [unclear - possibly a specific entity or entity], specifically, since the session key is secretly shared, both parties need to interact and execute the 2PC protocol to construct the TLS record encryption. While a general-purpose 2PC protocol would be theoretically sufficient, it would be expensive for larger queries. Instead, we introduced a more efficient, custom-designed 2PC protocol.

[0176] We will first focus on a single-round conversation, in which Send all queries to [the relevant server] before receiving any response. Most applications of DECO (e.g., proving the origin of content retrieved via HTTP GET) are one-round processes. Extending DECO to support multi-round sessions is described elsewhere in this document.

[0177] CBC-HMAC. Remember. and Storing shared MAC keys, while Store the encryption key. This is used to construct the TLS record encryption. (potentially) (For private purposes), both parties first run the 2PC protocol to calculate The HMAC tag τ, and then Encrypt locally And send the encrypted message to

[0178] Assume H refers to SHA-256. Remember that the HMAC of message m with key k is...

[0179]

[0180] The terms ipad and opad refer to the corresponding "internal" and "external" values ​​used in the HMAC algorithm. A direct 2PC implementation would be expensive for larger queries because it requires hashing the entire query in the 2PC to compute the internal hash. This is achieved through... The computation of the internal hash locally (i.e., in the absence of 2PC) is advantageously avoided in the illustrative embodiments. If Know Then she can calculate the internal hash. However, we cannot simply... Give Because she can then learn k and forge MAC.

[0181] Our optimization utilizes the Merkle-Damgard pattern in SHA-256. Structure. Assume m1 and m2 are two correctly sized blocks. Then, calculate H(m1‖m2) as f H (f H (IV,m1),m2), where f H IV refers to the one-way compression function of H, and IV refers to the initial vector.

[0182] Figure 9 This demonstrates the post-handshake protocol used for CBC-HMAC.

[0183] After the three parties shook hands and Execute the simple 2PC protocol to compute And to Revealed. In order to compute the internal hash of message m, The hash of m is computed using only s0 as the IV. Revealing s0 does not reveal k. MAC Because of the assumption f H It is unidirectional. To compute HMAC(k,m), the outer hash in the 2PC on the inner hash is then involved, which is a much shorter message. Therefore, compared to up to 256 SHA-2 blocks per record with a general 2PC, we are able to reduce the amount of 2PC computation to a few blocks without considering the query length.

[0184] AES-GCM. Regarding GCM... and conduct The authentication encryption is simple using 2PC-AES with optimized circuitry, but computing tags for larger queries is expensive because it involves evaluating long polynomials in a large domain for each record. Our optimized protocol performs polynomial evaluation locally via pre-computation, as described in more detail elsewhere in this paper. Because 2PC-GCM involves not only tag creation but also AES encryption, it incurs higher computational costs and latency than CBC-HMAC.

[0185] Other embodiments disclosed herein utilize efficient alternative protocols (referred to as proxy mode protocols) that completely avoid the post-handshake 2PC protocol under additional trust assumptions.

[0186] like Figure 6 As illustrated in the complete DECO protocol, after querying the server and receiving a response, By sending ciphertext And submit to the session, and receive MAC key sharing. Next... The integrity of the response can be verified, and the statements made about it can be proven. Figure 6 Specify the complete DECO protocol for CBC-HMAC. The DECO protocol for GCM is similar and is described elsewhere in this document.

[0187] For clarity, we have removed the ideal functionality. Details of zero-knowledge proofs. From... Upon receiving (“proof”, x, w), where x and w represent private and public witnesses respectively, Send w and the relation π(x,w)∈[0,1} (defined below) to Specifically, for CBC-HMAC, x, w, and π are defined as follows: and The relation π(x,w) holds if and only if (1) (and )for (and R) in key k Enc ,k MAC The following is the CBC-HMAC ciphertext; (2) And (3) Stmt(R) = b outputs 1. Otherwise, it outputs 0.

[0188] Assuming functionality for secure 2PC and ZKP, it can be demonstrated as follows: Figure 6 The Prot described in DECO UC securely achieves this against malicious adversaries. Figure 3 of

[0189] More specifically, assuming the discrete record problem is difficult in the group used in the three-way handshake, and f (the compression function of SHA-256) is a random oracle, then Prot DECO UC securely implements anti-malicious static adversaries with termination capabilities. In the mixed world

[0190] The protocol used for GCM has a similar process. The GCM variant of the three-way handshake and query construction protocol was described above.

[0191] Figure 10 This demonstrates the 2PC protocol used for tag verification and record decryption in a GCM variant. These are also known as the post-handshake protocols applied to GCM.

[0192] Unlike CBC-HMAC, GCM does not commit: for a given ciphertext encrypted with key k Those who know k can efficiently find the key to pass integrity checks. Decrypting into different plaintexts, k′≠k. To prevent this attack, we need... In learning The key sharing was submitted to her key sharing before. In the proof generation phase, besides proving about In addition to R's statement, It is also necessary to prove that it is used for decryption and Session keys for The submission is valid. The proof of security for the GCM variant is similar to the proof of security for CBC-HMAC.

[0193] Proof generation

[0194] Remember the proof device Ciphertext submitted to the TLS session And towards Prove that plaintext M satisfies certain properties. Without loss of generality, we assume... M contains only one TLS record, which will hereafter be referred to as the ciphertext record and the plaintext record. Multi-record sessions can be handled by repeating the protocol for each record.

[0195] Proving the provenance of M is simple: just reveal the encryption key. But this sacrifices privacy. Alternatively, Any statement about M can be proven using general zero-knowledge techniques. However, such proofs are often expensive.

[0196] In the following description, we present two categories of statements optimized for instance applications: revealing only a substring of the response while proving its origin (“selective openness”), or further proving that the revealed substring appears in a response by... In the expected context ("Contextual integrity through two-stage resolution").

[0197] Selective Opening. Illustrative embodiments implement the technology referred to herein as "selective opening," which allows... Efficiently reveal or revise substrings in plaintext. Assume the plaintext record consists of information blocks M = (B1, ..., B...). n The structure (details of which are discussed below) is selectively open. Prove that the ith information block of M is B. i However, this does not reveal the rest of M; we call this the revelation pattern. It can also be proven that M... -i Similar to M, but with the removed information blocks. We call this the revision mode. Both modes are simple but can be used for practical privacy goals. The granularity of selective disclosure depends on the cryptographic group, which we will now discuss.

[0198] CBC-HMAC. Remember that for the proof to be generated, Save encryption and MAC keys k Enc and k MAC Both, and Only has MAC key k MAC Our performance analysis assumes a cryptographic set of SHA-256 and AES-128 that matches our implementation scheme, but the techniques are applicable to other parameters. Remember to use MAC followed by encryption: the plaintext record M contains up to 1024 AES data blocks and 3 MAC tag blocks σ, which we refer to as M = (B1,…B ... 1024 ,σ), where σ=(B 1025 B 1026 B 1027 ). The CBC encryption for M consists of the same number of blocks: in

[0199] Reveal TLS records. Proof Without revealing k Enc An immature approach to encrypting M in this case would be to prove the correct encryption of every AES block in ZKP. However, this would require up to 1027 AES calls in ZKP, resulting in infeasible performance.

[0200] By using MAC followed by encryption, the same operation can be performed using only three AES calls in ZKP. This illustratively involves proof. The last few blocks are encrypted with tags σ, directly revealing the plaintext. Specifically, calculate

[0201]

[0202] And send (M,π) to then Verify π and check the MAC tag on M (note that...) Knowing the MAC key). Its security relies on the collision resistance of the underlying hash function in HMAC, that is, It is impossible to find an M′≠M with the same label σ.

[0203] Reveal the record with the revised block. Assume the ith block contains The sensitive information to be revised. The direct strategy is to prove B through computation. i- =(B1,…,B i-1 ) and B i+ = (B i1+ ,…,B n Formed through Prefix and suffix of encrypted plaintext

[0204]

[0205] However, this is expensive because it involves 3AES and 256SHA-256 compression in ZKP.

[0206] Using the Merkel-Dumgard structure of SHA-256, several optimizations are possible. Assume f represents the SHA-256 compression function, and s... i-1 Refers to B i- The state after applying f. First, if it is possible, for example, in B... i Reveals s when containing high-entropy data such as API keys i-1 and s i If both are true, then the above goal can be achieved using only 1SHA-256 from ZKP. To do this, Calculate π = ZK - PoK{B i :f(s i-1 B i ) = s i And (π.s) i-1 ,s i B i- B i+ Send to Then 1) through B i-Recalculate it to check s i-1 ;2) Verify π; and 3) By means of s i and B i+ Recalculate it to check the MAC label σ. Assume B i Since f is high entropy, and f is unidirectional, it reveals that s... i-1 and s i No leakage of B i .

[0207] On the other hand, if s i-1 and s i Neither can reach Reveal (e.g., when targeting B) i If a forced attack is feasible, then we can still achieve this by using... Revision containing block B i The cost is reduced by prefixing (or suffixing) the record. The subsequent cost is the 256-iSHA-2 hash in ZKP. Additional details are provided elsewhere in this document. Generally, ZKP costs are proportional to record size, so TLS fragmentation operations can also have their costs reduced by a constant factor.

[0208] Revise suffixes. When revising the suffix B... i+ hour, calculate And s i For B i- ||B i The state after applying f. (π, B) i- ||B i 0 sent to The validator then 1) passes through B i- ||B i Use f to check s i-1 , and 2) verify π. Basically, its security follows the pre-imaging resistance of f. Furthermore, since ih = f(s, B i+ )Towards Keep it a secret, so The revised suffix is ​​not learned. The total cost is 3AES and 256-iSHA-2 hashes in ZKP.

[0209] Revise the prefix. Calculate two ZKPs: 1) Let (π1,π2,s) i-1 B i ||B i+ Send to Validator 1) uses π1 to check s i-1To be correct, then calculate f(s). i-1 B i ||B i+ 1) Obtain the internal hash ih, 2) Verify π2 using the calculated ih. The cost incurred is 3AES and 256-i SHA-2 hash in ZKP.

[0210] It should be noted that revising the prefix / suffix is ​​only meaningful if the disclosed portion does not contain any private user data. Otherwise, We will have to find the smallest substring containing all the sensitive blocks and revise the prefix / suffix, similar to the above.

[0211] Unlike CBC-HMAC, revealing blocks is highly efficient in GCM. First, Reveal AES(k,IV) and AES(k,0) with proofs of correctness in ZK, to allow Verify the integrity of the ciphertext. Next, in order to reveal the ith block, Only reveal the ith counter C with proof of correctness. i =AES(k,inc i (IV) encryption. The ith block can be decrypted because This is the public initialization vector used for the session, and inc i (IV) refers to incrementing IV i times (the exact format of inc is not important). To reveal a TLS record, The above protocol is repeated for each block. Additional details are also provided elsewhere in this document.

[0212] In summary, CBC-HMAC allows for efficient selective disclosure at the TLS record level and at the revision level within the DECO, while GCM allows for efficient disclosure at the block level. Selective disclosure can also serve as preprocessing to reduce the input length required for subsequent zero-knowledge proofs.

[0213] Contextual integrity through two-stage resolution. For many applications, validators... However, it is necessary to verify that the revealed substring appears in the correct context. We call this property "contextual integrity." In the following sections, we present examples used for... Technologies and methods for specifying context A technique for efficiently proving contextual integrity.

[0214] For ease of explanation, our following description initially focuses on revealing patterns, namely, Reveal server to The response substring. Next, the revision mode will be described.

[0215] Context specification. Our technical assumptions for specifying the context are sent to a given server. and the TLS-protected data sent from the server have a relationship with and Both are known to have well-defined, context-free syntax. In the case of slight misuse of symbols, we assume It refers to both the grammar and the language it specifies. Therefore, Refers to passing Given a string R in a language. We assume To be clear, that is, each With a unique associated parse tree T R JSON and HTML are two widely used languages ​​that meet these requirements, and they are our focus here.

[0216] when Then it will be presented from Some substrings of response R 开放 At that time, we said that in order to pass R is expected to be generated in a certain way. 开放 In the case of R 开放 It has contextual integrity. Specifically, Given a set of positions S, she can expect to see a valid substring R of R at those positions. 开放 In our definition, S is derived from... A set of paths from the root to internal nodes in a defined parse tree. Therefore, s∈S, we call the non-terminal sequence an allowable path. Assume ρ R Refers to T R The root ( (The parse tree of R in the text). We say if T R It has a subtree (whose leaves produce (i.e., concatenate to form) the string R) 开放 ), then string R 开放 It has contextual integrity relative to (R, S) and there exists a relationship from ρ R The path s∈S to the root of the tree.

[0217] In form, we base our assertions on... Define context integrity. More specifically, in giving a TLS response The syntax above The substring R of R 开放 Given a set of permissible paths S, we will use the context function. Defined as a Boolean function, such that there exists a function with respect to Boolean functions if and only if there exists a function with respect to Boolean functions. arrive The path s∈S of TR subtree and Generate R 开放 hour, R 开放 It is said that in In the true case, it has contextual integrity relative to (R,S).

[0218] Refer again Figure 5 For example, consider the JSON string J based on the given example. JSON contains (roughly) the following rules:

[0219] Start → Object → {Pair}

[0220] Pair → "key": value pair → pair | pair, pair

[0221] Key → chars Value → chars | Object

[0222] In the example described, Learning is achieved by pairing the key "check a / c" with ρ 检查 The value given is paired with the key "balance" in the object. 余额 The export is of interest. Each of these non-terminal elements is used in the parse tree T. J The label of the node in T. J From the root to ρ 检查 The path requires traversing the form: start with object → pair * → ρ 检查 The sequence of nodes, where * represents a sequence of zero or more pairs. Therefore, S is a set of such sequences and R... 开放 For the string "Check a / c": {"Balance": $2000}.

[0223] Two-stage analysis. Generally, proving R without directly revealing R. 开放 It has contextual integrity, that is, This is due to calculation However, it may be necessary to compute T for potentially long strings R. R However, we observed that, under certain assumptions that TLS-protected data typically satisfies, it is possible to achieve this by enabling... By application and The protocol transforms Trans and preprocesses R to remove much overhead, and it is proven that R... 开放 Compared to R′ (usually a much shorter string) and S′ (by... (Based on a set of permissible paths specified by S and Trans) it has contextual integrity.

[0224] Based on this observation, we introduce a method for efficiently computing R. 开放and proof Assumption and agreement The syntax used by the web server, and the transformation (Trans). Assume... For use in all The syntax for the string Trans(R). Based on Trans, Specify the permissible path S′ and constraint check function In the first phase, (1) Calculate the substring R of R by parsing R. 开放 (make) (2) Calculate another string R′ = Trans(R). In the second stage, With zero knowledge Proof (1) and (2) It should be noted that, in addition to the publicly available parameters S, S′, Trans, In addition, the validator only sees submissions to R, and finally, R... 开放 .

[0225] This protocol makes zero-knowledge computation significantly cheaper by deferring actual resolution to unverifiable computation. In other words, and The calculation is comparable The calculation is much more efficient.

[0226] We formalize the correctness conditions for two-phase parsing in the operational semantic rules given below. Here,<f,σ> This refers to applying the function f to the input σ, while This means that if premise P is true, then conclusion C is true.

[0227] In a given grammar Context functions and allowed paths Transformation, context functions, and permissible paths sum function grammar In this case, we say that if for all (R,R′,R) 开放 ) makes Boolean type b, then For any case where S is correct, the following rule holds true:

[0228]

[0229] The following sections focus on instance syntax suitable for DECO applications and present the specific construction of a two-stage parsing scheme.

[0230] Key-value syntax. A wide range of data formats, such as JSON, have the concept of key-value pairs. Therefore, it is our focus in some implementations of DECO.

[0231] Key value syntax According to the rule "right → start Key middle value Finish "Generate key-value pairs, where" start , middle and Finish `x` is the delimiter. For this syntax, optimized arrays can significantly reduce the complexity of the proof context. We discuss several such optimizations below, with other details provided elsewhere in this paper.

[0232] For revealing globally unique keys. Regarding key value syntax. Path group S, if for Substring R that conforms to context integrity 开放 R needs to be set using a globally unique key K 开放 If it is parsed into a key-value pair, then R 开放 It only requires a substring of R and to be correctly parsed into a pair. Specifically, Trans(R) outputs a substring R′ of R containing the required key, i.e., of the form " start K middle value Finish "and The substring can be output as R 开放 =R′. Can be determined by rules in For use The start symbol in the generation rule. Next (1) Check that R′ is a substring of R and (2) for Check (a) and (b)R 开放 =R′. In some applications described in this paper, globally unique keys are generated, such as when selectively opening responses to age.

[0233] Revisions to the key-value syntax. To date, our description of the two-stage parsing assumes the revelation of a pattern, where... Towards Reveal the substring R of R 开放 And prove R 开放 Compared to The specified group of permissible paths has context integrity. The process is similar in revision mode, but... Using the previously described technique, generate an R 开放 Submission and in removing R 开放 In cases such as when R is revealed by replacing its position with a dummy character, rather than by clearly revealing R. 开放 .

[0234] application

[0235] The DECO disclosed in this paper can be used in any oracle-based application. To illustrate its versatility, we have implemented and evaluated three example applications that utilize its various capabilities: 1) confidential financial instruments implemented by smart contracts; 2) converting traditional credentials into anonymous credentials; and 3) privacy-preserving price discrimination reporting.

[0236] Confidential financial instruments and derivatives are among the most frequently cited applications of smart contracts, illustrating the need for certified data feeds (e.g., stock prices). For example, a popular financial instrument easily implemented in smart contracts is a binary option. This is an agreement between two parties regarding the price P of some asset N at a specified future time (e.g., the end of day D). * Will it be equal to or exceed the predetermined target price P (i.e., P)? * The contract for betting (≥P). The smart contract implementing this binary option can invoke an oracle. To determine the result.

[0237] In principle, for binary options in the chain, It can hide the underlying asset N and the target price P. It only accepts off-chain option details and only reports the specified result Stmt:=P. * ≥? The bits of P. This method is called Mixicle.

[0238] The limitation of the basic Mixicle construction is that... Learn the details of financial instruments yourself. Before DECO, only Trusted Execution Environment (TEE) oracle services could be used to... Hidden queries. We will now show how DECO can... The exercise of binary options is supported without learning the details of the financial instrument (i.e., N or P). It should be noted in this regard that the assertion direction ≥? or ≤? can be randomized. Furthermore, the identities of winners and losers and payout amounts can be hidden. Additional steps can be taken to hide other metadata, such as the exact settlement time.

[0239] In this example application, the options winner plays a role. The role, and from the perspective of giving full play to The function Obtain the signed result Stmt. We will now describe the protocol and its implementation.

[0240] Assumption This refers to the key pair used by the oracle. In this embodiment, the binary option is specified by the asset name N, the threshold price P, and the settlement date D. We use a witness r M C M =com(M,r M () refers to the submission of message M.

[0241] Figure 11 This describes the two parties, Alice and Bob, exercising a confidential binary option. Alice uses a DECO to access the stock price API and enables... She is certain she has won. Instances of requests and responses are shown to the right, and the shaded text in this section of the diagram represents sensitive information awaiting revision.

[0242] Figure 11 The binary option process described herein includes the following steps:

[0243] 1) Setup: Alice and Bob agree on a binary option {N, P, D} and create an identifier ID. SC The smart contract SC. The contract contains The addresses of each party and the options with witnesses known to both parties {C} N C P C D The submission of}. It also agrees to publicly disclose the parameter θ. P (For example, a URL used to retrieve asset prices).

[0244] 2) Settlement: Assume Alice wins the trade. To claim payment, she uses DECO to generate ZKP matching the current asset price at her location. Alice and Execute the DECO protocol (where (act as a validator) to obtain from θ P (Target URL) retrieves asset prices. We assume the response contains (N * ,P * D * (Except for ZKP in DECO to prove the origin of θ) P In addition, Alice also proves the following statement:

[0245] ZK-PoK{P,N * ,P * D * ,r N ,r P r D :(P≤ * )∧

[0246] C N =com(N* ,r N )∧C P =com(P,r P )∧C D =com(D * ,r D )}.

[0247] Upon successful verification, the oracle immediately returns a symbolic statement ID along with the contract.

[0248] 3) Payment: Alice provides a signed statement S to the contract, which verifies the signature and pays the winner.

[0249] Alice and Bob need to trust each other. The integrity of the data (but not privacy) is guaranteed. As explained elsewhere in this article, this can be further hedged by using multiple oracles to offset the failure of the integrity data. Trust on decentralized oracles is a standard and deployed technique. We emphasize that DECO ensures privacy even if all oracles are malicious.

[0250] As indicated above, Figure 11 Displays the requests and responses from the stock price API. (User) We also need to provide oracles Reveal enough parts of the HTTP GET request to be sure that access is to the correct API endpoint. A GET request contains several parameters, some of which are revealed to resemble the API endpoint, while others contain sensitive details such as stock names and private API keys. Revising sensitive param using the techniques disclosed in this article and directing... Reveal the rest. API keys are provided to prevent... Learn sufficient entropy for sensitive parameters. However, without additional attention, cheating... The semantics of GET requests can be altered, and cheating can be hidden by revising additional parameters. To ensure this does not happen, It needs to be proven that the delimiter “&” and the separator “=" do not appear in the revised text.

[0251] Assumption R and R refer to the ciphertext and plaintext of the response, respectively. For option settlement, Using the previously described two-stage parsing scheme to... Prove that R contains evidence that he won the option. In the first phase, Locally parse R and recognize that it allows The smallest known substring of R. (In the context of stock prices) Figure 11 In the embodiment, R 价格="05.price":"1157.7500" is acceptable. In the second stage, Prove (R) using ZK 价格 ,P,r P The knowledge of ) makes 1)R 价格 for 2) R 价格 It begins with "05.price"; 3) Subsequent characters form the floating-point number P. * And the P * ≥P; and 4)com(P,r P ) = C P .

[0252] Assuming the key is unique and the key "05.price" is followed by the price, then this two-stage parsing is secure, making the syntax of the response a key-value syntax with a unique key, as described above. Similarly, Prove that the stock name and date contained in R match the submission. In the case of the CBC-HMAC cryptographic program group, the zero-knowledge proof circuit involves revising the entire record (408 bytes), calculating the submission, and string manipulation.

[0253] HTTP GET requests (and HTML) have special restrictions: the boundary between the key and the value (i.e., middle ) and the beginning of the key-value pair (i.e., start ) is never a substring of a key or value. This means that in order to revise more than a single consecutive key or value, The revision of { is required} middle , start The characters within}. Therefore, we make... Check: (1) |R| = |R′|; and (2) Or R[i] = R′[i] (D is a dummy character used for in-situ revision). Then there's no need to check.

[0254] From Traditional Credentials to Anonymous Credentials: Age Verification. User credentials are typically inaccessible outside the service provider's environment. Some providers offer third-party API access via OAuth tokens, but these tokens reveal a user identifier. DECOs allow users to store credentials in an existing system (which we call "traditional credentials") to anonymously verify statements about them to third parties (verifiers). Therefore, in some implementations, DECOs allow users to convert any web-based traditional credentials into anonymous credentials without server-side support or trusted hardware.

[0255] Figure 12This example demonstrates an application where a student uses credentials (demographic details) stored on the university's website to prove she / he is 18 years of age or older. The student can provide this proof of age to any third party, such as a government issuing a driver's license or a hospital seeking medical clearance. We implement this example using the AES-GCM cryptographic suite and optimized two-phase resolution based on a unique key.

[0256] exist Figure 12 In this example, the student's demographic details stored on the university website include name, date of birth, student ID, etc. The highlighted text contains the student's age. The reveal pattern is used in conjunction with two-stage parsing. The prover parses 6 to 7 AES blocks containing the date of birth and proves to the validator in ZK that she is over 18 years old. Similar to other examples, this is attributed to the unique HTML tags surrounding the date of birth, which also serve as the key value syntax with a unique key. Similar to binary options applications, this example requires additional string processing to parse the date and calculate the age.

[0257] Price discrimination refers to selling the same product or service to different buyers at different prices. The ubiquitous nature of consumer tracking allows online shopping and booking websites to employ sophisticated price discrimination methods, such as adjusting prices based on customers' postal codes. Price discrimination can generate economic efficiency and is therefore widely permissible under existing laws.

[0258] However, in the United States, the FTC prohibits price discrimination if it causes competitive harm, while new privacy-focused European laws (such as the GDPR) have re-emphasized the legality of such practices. Consumers generally do not want to experience price discrimination under any circumstances. However, currently, there is no credible way for users to report online price discrimination.

[0259] Figure 13 This demonstrates an example of the application where DECO allows buyers to make a verifiable claim about perceived price discrimination by proving that the advertised price of a product is above a threshold, while hiding sensitive information such as name and address. We implement this example using the AES-GCM cipher suite for TLS sessions and reveal 24 AES blocks containing the necessary order details and request URL.

[0260] like Figure 13As explained, the order invoice page in the HTML of a shopping website (such as Amazon) contains personal details such as the buyer's name and address. The buyer wants to convince a third party (verifier) ​​of the price charged for a specific product on a specific date. In this example, we use an AES-GCM cryptographic set and a reveal pattern to reveal the necessary text in the upper part of the order invoice page, while the shaded sensitive text in the lower part (containing the shaded buyer's name, address, and city) is hidden. The number of AES blocks revealed from the response is 20 (due to the longer product name). Additionally, 4 AES blocks from the request are revealed to prove that the correct endpoint has been accessed. Contextual integrity is ensured by revealing unique strings around the item price; for example, the string "Order Total∶" near the item price appears only once in the entire response.

[0261] Implementation plan and assessment

[0262] We will now describe the implementation details and evaluation results of DECO and three applications.

[0263] Three-way handshake and query execution. We implement the three-way handshake protocol (3P-HS) and query execution protocols (2PC-HMAC and 2PC-GCM) for TLS 1.2 in approximately 4700 lines of C++ code. We construct a manually optimized TLS-PRF circuit with a total AND complexity of 779,213. We also use a variant of a known AES circuit. Our implementation uses Relic for the Paillier cryptosystem and the EMP toolkit for the malicious secure 2PC protocol.

[0264] We integrate the three-way handshake and 2PC-HMAC protocol with the popular TLS implementation mbedTLS to build an end-to-end system. 2PC-GCM can be similarly integrated into TLS with more engineering effort. We evaluate the performance of 2PC-GCM separately. The performance impact of integration should be negligible. We did not implement 3P-HS for TLS 1.3, but believe its performance should be comparable to that for TLS 1.2 due to similar circuit complexity.

[0265] We evaluated the DECO's performance in both LAN and WAN settings. Both the prover and validator ran on a c5.2xlarge AWS node with 8 vCPU cores and 16GB of RAM. In the LAN setting, the two nodes were located in the same region (but different availability zones), while in the WAN setting, they were located in two different data centers (in Ohio and Oregon). The round-trip time between the two nodes in LAN and WAN was approximately 1ms and 67ms, respectively, with a bandwidth of approximately 1Gbps.

[0266] Table 1 below summarizes the runtime of the DECO protocol during a TLS session. The mean and standard error of the mean were calculated using 50 samples (in parentheses). The MPC protocol we used relies on offline preprocessing to improve performance. Because the offline phase is input-independent and target-independent, it can be performed before the TLS session. Only the online phase is on the critical path.

[0267]

[0268] Table 1: 3P-HS runtime and query execution protocol. All times are in milliseconds.

[0269] As shown in Table 1, the DECO protocol is highly efficient in LAN settings. It takes 0.37 seconds to complete the three-way handshake. For query execution, 2PC-HMAC is efficient (0.13s per record) because it involves only one SHA-2 evaluation in 2PC, regardless of record size. 2PC-GCM is generally more expensive, and the cost depends on the query length because it involves 2PC-AES over the entire query. We evaluated its performance with queries ranging from 256B to 2KB (typical sizes seen in HTTP GET requests). In LAN settings, its performance is efficient and comparable to 2PC-HMAC.

[0270] In a WAN setup, runtime is dominated by network latency, as MPC involves numerous rounds of communication. However, performance remains acceptable in a DECO environment where only periodic use of most of the applications we are considering is likely to be observed.

[0271] The proof is generated. We instantiate zero-knowledge proofs using the standard proof system in libsnark. We have designed a statement template that can be proven efficiently, but DECO users need to adapt it to their specific applications. The SNARK compiler implements this adaptation in a high-level language, thus hiding the low-level details from the developer. We use xjsnark and its Java-like high-level language to build the statement template and libsnark-compatible circuits.

[0272] Our primary reason for choosing libsnark is its relatively mature tooling support. Proofs generated by libsnark are of constant size and verification is highly efficient, but the downside is per-circuit trusted setup. With further effort, DECO can be adapted to use, for example, Bulletproof, which does not require trusted setup but has a longer proof and verification time.

[0273] For each instance, we measured five performance metrics: prover time (time to generate a proof), verifier time (time to verify a proof), proof size, number of arithmetic constraints in the circuit, and peak memory usage during proof generation.

[0274] Table 2 below summarizes the results. The mean and standard error were calculated using 50 samples. DECO achieves very practical prover performance through the use of efficient statement templates and two-stage parse. The prover time is negligible due to libsnark's optimization for low verification overhead. The binary option application has the highest number of constraints (and prover time) attributable to additional string parsing routines. We use multiple proofs in each application to reduce peak memory footprint. For the most complex application, the memory footprint is 1.78 GB. The size of the proofs shown is a multiple of this size, as libsnark proofs are a constant 287 B.

[0275]

[0276] Table 2: Costs of generating and validating ZKPs during the proof generation phase of the DECO for application.

[0277] End-to-end performance. DECO's end-to-end performance depends on the available TLS cipher suite, the size of the private data, and the complexity of the application-specific proof. Here we present the end-to-end performance of the most complex application (binary options) among the three applications we implemented. The protocol takes approximately 13.77 seconds to complete, which includes the time spent generating an unforgeable commit (0.50 seconds), running the first phase of two-phase resolution (0.30 seconds), and generating a zero-knowledge proof (12.97 seconds). These figures are calculated in a LAN setting; in a WAN setting, the MPC protocol is more time-consuming (5.37 seconds), pushing the end-to-end time to 18.64 seconds.

[0278] In comparison, Town Crier uses a TEE to execute a similar application in approximately 0.6 seconds (i.e., about 20x faster than DECO), but with added trust assumptions. Since DECO is likely to be used only periodically for most applications, the overhead of implementing cryptographic strength security guarantees seems reasonable.

[0279] Legal and compliance issues

[0280] Although users may have retrieved their data from the website, DECO allows users to output data with proof of integrity without their explicit approval or even awareness. We will now briefly discuss the resulting legal and compliance considerations.

[0281] However, crucially, DECO users cannot unilaterally export data with integrity guarantees to third parties; instead, they rely on oracles to act as validators for this purpose. While DECO keeps user data private, oracles learn about the websites and types of data users visit. Therefore, oracles can enforce appropriate data usage, for example, rejecting transactions that could lead to copyright infringement.

[0282] Both users and oracles are legally responsible for the data they access. However, recent case law on the Computer Fraud and Abuse Act (CFAA) demonstrates a shift towards criminalizing web scraping, and federal courts have ruled that violating a website's terms of service is not itself a criminal offense. Users and oracles that violate website terms of service (e.g., "click wrap") now risk civil penalties. DECO compliance with a given site's terms of service is a site- and application-specific matter.

[0283] Oracles have an incentive to establish themselves as trustworthy within smart contracts and other ecosystems. We expect reputable oracles to provide users with a menu of specific verifications they publish and their permitted target websites, to vet these options to maximize security and minimize liability, and to potentially notify or collaborate with the target server.

[0284] The legal, performance, and compliance implications of incorrect verification based on flawed (and potentially compromised) data are also important. However, today's internet services have complex multi-site data dependencies, so these issues are not unique to DECO. Oracle services have relied on multiple data sources to help ensure correctness. Oracle services often end up with an infrastructure similar to a certificate infrastructure, incorporating online verification and revocation capabilities and different layers of security.

[0285] The DECO in the illustrative embodiments disclosed herein is a privacy-preserving, decentralized oracle scheme for modern versions of TLS that requires no modifications to trusted hardware or the server side. DECO allows provers to generate unforgeable commits to TLS sessions and efficiently proves statements about the session content. Some embodiments utilize novel two-phase resolution schemes to mitigate context integrity attacks common to privacy-preserving oracles. DECO can release data from a centralized network service repository, making it accessible to a wide range of applications. The utility of DECO is demonstrated herein through a full-featured implementation along with three example applications.

[0286] GCM Protocol Details

[0287] GCM is an Authentication Encryption with Additional Data (AEAD) cipher. For encryption, the GCM cipher takes the tuple (k, IV, M, A) as input: the secret key, the initialization vector, the plaintext of multiple AES blocks, and the additional data to be included in the integrity protection; its output is ciphertext C and a tag T. Decryption reverses the process. The decryption cipher takes (k, IV, C, A, T) as input and first checks the integrity of the ciphertext by comparing the recalculated tag with T, then outputs the plaintext.

[0288] Calculate the ciphertext in counter mode: Among them, inc i It refers to incrementing IV i times (the exact format of inc is not important).

[0289] The label (k, IV, C, A) is calculated as follows. Given a vector... In the case of associated GHASH polynomials Used in The addition and multiplication performed are limited to: Without loss of generality, assume that A and C are appropriately filled in. Assume l A and l C Refers to its length. The GCM tag is...

[0290]

[0291] Where h = AES(k,0).

[0292] When using GCM in TLS, each plaintext record D is encrypted as follows: A unique temporary value n is chosen, and additional data κ is calculated as a concatenation of the sequence number, version, and length of D. GCM is invoked to encrypt the payload record as M = n‖GCM(k,n,D,κ).

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

[0294] Query execution

[0295] Label creation / verification. Calculating or validating GCM labels involves evaluating the above equation (1) in a 2PC. The challenge for equation (1) involves arithmetic calculations (e.g., Both polynomial evaluation in binary circuits and binary computation (e.g., AES) are involved. Multiplication over large domains in binary circuits is expensive, while... Calculate AES(in GF(2)) 8 The definition in () leads to high overhead. Even if the computation can be separated into two circuits in some way, only the polynomial is evaluated (this is for each record in) Using approximately 1,000 multiplications would also be excessively expensive.

[0296] Our protocol eliminates the need for polynomial evaluation. The actual 2PC protocol involves only binary operations and can therefore be completed in a single circuit. Furthermore, the computation per record is reduced to just one call in 2PC-AES.

[0297] This is achieved by calculating (in the 2PC protocol) {h} during the preprocessing phase at the beginning of the session. i This is achieved through sharing `h`. Since the same `h` is used for all subsequent records, the preprocessing overhead is amortized over the session. i} sharing, and Polynomial evaluation can be computed locally. The sharing of Tag(k,IV) is also calculated in 2PC to obtain the sharing of Tag(k,IV,C,A). In general, only one call to 2PC-AES is needed to check the tag for each record.

[0298] The important thing is, Never respond to the same IV more than once; otherwise We will learn h. Specifically, in each response, Revealing Her shared form Blinding of linear combinations. Importantly, the values ​​are blinded via AES(k,IV) because... A single non-blind linear combination will allow Solve for h. Therefore, if If the same IV is responded to twice, then two responses can be added (in...) (in Chinese) to remove blinding: This follows the GCM's requirement for the uniqueness of temporary values.

[0299] Encrypt / decrypt records. Once the tags are properly checked, decrypting the records is straightforward. and Simply calculate the AES encryption of inc′(IV) using 2PC-AES. A subtle point to note is that... It must be checked that the counter to be encrypted has not been previously used as an IV. Otherwise, h will be learned in a manner similar to that outlined above.

[0300] Proof generation

[0301] Revealing block. Want to make Confirm AES block B i To encrypt records The proof strategy is as follows: 1) Prove the AES block B. i Encrypt to ciphertext block And 2) Prove the label is correct. Proving correct encryption requires only 1 AES in ZKP. In a premature manner, proving the label is correct triggers the evaluation of a 512-order GHASH polynomial and 2 AES block encryptions in ZKP.

[0302] We are able to allow Towards Revealing two encrypted messages, AES(k,IV) and AES(k,0), to achieve a much more efficient proof, thus allowing... Verify the label (see Equation (1)). Only proving the correctness of the encryption in ZK and that the key used corresponds to the submission is required, thus 2AES and 1SHA-2 are needed. By revealing the hash of the key, submit to Therefore, the total cost in ZKP is 3AES and 1SHA-2.

[0303] Revealing TLS records. Proof techniques are a simple extension of the above. Reveal the entire record rec and prove the correct AES encryption of all AES blocks, thus producing a total of 514 AES and 1 SHA-2 in ZKP.

[0304] Reveal TLS records other than blocks. Similar to the above situation, Prove the encryption of all blocks in the record except for one block, thus producing a total of 513 AES and 1 SHA-2 in ZKP.

[0305] Protocol extension

[0306] Adapted to support TLS 1.3. To support TLS 1.3, the 3P-HS protocol must be adapted to the new handshake procedure and different key derivation circuitry. It's worth noting that all handshake messages after ServerHello are now encrypted. An immature strategy would involve decrypting these messages in 2PC, which would be expensive because certificates are typically large. However, thanks to the key independence nature of TLS 1.3, and The handshake encryption key can be securely revealed without compromising the secrecy of the final session key. Because the completion message uses a separate key to authenticate the handshake, the integrity of the handshake is protected.

[0307] Therefore, the optimized 3P-HS works as follows. and The ECDHE process is performed as before. Then, it derives the handshake and application key by executing 2PC-HKDF, and sends it to... Reveal the handshake key, thereby allowing The handshake message is decrypted locally (i.e., without 2PC). The 2PC circuit involves approximately 30 calls to SHA-256, totaling about 70k AND gates, comparable to those used for TLS 1.2. Finally, since CBC-HMAC is not supported by TLS 1.3, the DECO can only be used in GCM mode.

[0308] Query construction is optional. For applications that bind responses to queries, such as when stock quotes are included with quotation marks, the 2PC query construction protocol can be completely avoided. Because TLS uses a separate key for each direction of communication, it is possible to send a separate key to the recipient after the handshake. Revealing the client-to-server key enables... Can be without Query the server in an interactive manner.

[0309] Supports multi-round sessions. DECOs are extensible to support multi-round sessions, where... Further queries are sent depending on the previous response. After each round, The above performs a similar 2PC protocol to verify the MAC tag of the incoming response because MAC verification and creation are symmetrical. However, an additional commit is required to prevent... Abuse of MAC verification to forge labels.

[0310] In TLS, different MAC keys are used for server-to-client and client-to-server communication. To support multi-session sessions, and A 2PC is run to verify the tag used for the former and to create a tag for the latter on a new message. The previous descriptions in this document specified the protocol used to create (and verify) MAC tags. We now discuss additional security considerations for multi-round sessions.

[0311] When inspecting the tags of server-to-client messages, we must ensure It is impossible to forge a tag on a message that did not originally originate from the server. Assume... We want to verify the label T on message M. We make... First submit to T, then and Run the 2PC protocol to compute the label T′ on message M. Requirements: Open to The submission is valid and if T≠T′, then The agreement is terminated. Due to... I don't know the MAC key, so Unable to calculate and submit tags to messages that did not originate from the server.

[0312] When creating tags for client-to-server messages, As required by TLS, a MAC tag is created on the message with an incrementing sequence number. This also prevents malicious activity. Create two messages with the same sequence number because there is no available... Distinguish which one to send to the server.

[0313] Alternative to the DECO Protocol: Proxy Mode. As shown in Table 1, DECO's HMAC mode is efficient, and the runtime for creating and validating HMAC tags in 2PC is independent of record size. GCM mode is efficient for smaller requests with preprocessing, but can be expensive for larger records. We now present an efficient alternative to the 2PC protocol that completely avoids the handshake.

[0314] In this alternative, the validator Acting as a proof With TLS server inter-agency, i.e. pass Send the message to / Receive messages from it. The modified DECO protocol process is as follows: After the three-way handshake, Submitted to her key share then Towards reveal therefore, Now has the entire session key because Use 'k' to continue the session with the server, so Record the proxy transactions. After the session ends, The statement regarding the recorded session is the same as before.

[0315] In this implementation, the three-way handshake provides unforgeability. Unlike CBC-HMAC, GCM does not commit: given ciphertext and a tag (C, T0) encrypted with key k, it can be found that k′≠k when calculating the same tag, decrypting C into different plaintexts, because GCM MAC is not collision-resistant. To prevent such attacks, the above protocol requires... Submit to her key share before learning the session key.

[0316] The security properties and network assumptions associated with the proxy pattern protocol will now be described. The verifier integrity and privacy properties are clear because malicious... The integrity and privacy of TLS cannot be compromised (by assumption).

[0317] However, for prover integrity, we need to assume that the agent can reliably connect throughout the session. First, we assume that the agent can determine its actual relationship with... Connection. Furthermore, we assume that in the proxy and Messages sent between them cannot be transmitted by someone who knows the session key and therefore can modify the session content. tamper.

[0318] It should be noted that during the three-way handshake, The server's identity can be verified by checking the server's signature on the new temporary value (in standard TLS). However, after the handshake, It must rely on network layer identifiers, such as IP addresses. In practice, Therefore, it is essential to have correct and up-to-date DNS records, and The network between the server and the server (e.g., its ISP and backbone network) must be properly secured against traffic injection, such as traffic injection via Border Gateway Protocol (BGP) attacks. In the illustrative embodiment, there is generally no issue of eavesdropping.

[0319] These assumptions have been covered by other systems in similar proxy setups, as BGP attacks are challenging to implement in practice. We can further enhance our protocol's resistance to traffic interception by geographically distributing validator nodes. Furthermore, various known detection techniques can be deployed by the validators. BGP attacks are typically logged after the fact; therefore, the application of DECOs can be enhanced, where applicable, to support the revocation of affected sessions (e.g., when DECOs are used to issue credentials in an identity system).

[0320] This alternative protocol represents a different performance-security tradeoff. It is efficient because no dense cryptography occurs after the handshake, but it requires additional assumptions about the network and is therefore only vulnerable to weaker network adversaries.

[0321] Key value syntax and two-stage parsing

[0322] Preparation and notation. We refer to Context-Free Syntax (CFG) as... Where V is a non-terminal symbol, Σ is a terminal symbol, and P∶V→(V∪Σ) * Let S ∈ V be a set of production rules and V be the start symbol. We use '-' to refer to a set of subtractions and '..' to refer to a range to define the production rules for CFG using standard notation. For the string w, the parser determines whether to use a parse tree for w. The parse tree representation can then be used to extract the sequence of semantic generation rules.

[0323] Key-value syntax. These are syntaxes that use the concept of key-value pairs. These syntaxes are particularly interesting for DECO, since most API calls and responses are actually key-value syntax.

[0324] If syntax exists So Known as key-value syntax, it allows for the understanding of any... In this case, and It can be defined by the following rules:

[0325] S→Object

[0326] Object → No pairs of strings open, one or more pairs closed

[0327] → Start key intermediate value end

[0328] Pair → Pair one or more | ""

[0329] Key → chars

[0330] Value → chars | Object

[0331] chars→char chars|""

[0332] char → Unicode - escaped | escaped | added Chars

[0333] Special → Start Special | Middle Special | End Special

[0334] start → Unescaped s Start Special

[0335] middle → Unescaped m Special in the middle

[0336] Finish → Unescaped e End of Special

[0337] Escape → Special | Escape | ...

[0338] In the above text, S represents the beginning, not the end (meaning...). The sentence in the text) distinguishes between open and closed key-value pairs (not at the end) and not at the end. start , middle , Finish Special strings are used to distinguish the start of a key-value pair, the separation of the key and value, and the end of the pairing.

[0339] To eliminate ambiguity when parsing special characters (i.e., characters that have special meaning when parsing syntax), special non-terminal escape sequences are used. For example, in JSON, a key is parsed if it is preceded by a space double quote ("") and followed by another double quote. If the key or value expression itself must contain double quotes, then it must be preceded by a backslash (\), i.e., escaped. In the above rules, a non-terminal escape sequence before a special character means that it can be parsed as a special character. Therefore, going forward, we can assume that the generation of key-value pairs is explicit. Therefore, if the key-value syntax... If a substring R′ of string R in a given string is parsed as a pair, then R′ must correspond to a pair in the parse tree of R.

[0340] It should be noted that in the above key value syntax, middle An empty string cannot be exported; that is, a non-empty string must be marked. middle This allows the key to be parsed from the value. However, start and Finish One of them can have an empty derivation because it only distinguishes the separation between the value in one pair and the key in the next pair. Finally, we should note that in some embodiments, in the two-stage parsing of the key-value syntax, we only consider the string R with selective openness. 开放 The permissible path corresponding to a pair of requirements.

[0341] Two-stage parsing for locally unique keys. Many key-value syntaxes enforce key uniqueness within a range. For example, in JSON, it can be assumed that a key is unique within a JSON object, even if duplicate keys may exist across objects. Two-stage parsing of this syntax reduces the effort required to parse substrings. Specifically, Trans extracts a continuous substring R′ from R, making it possible to correctly determine the range of a pair even within R′. For example, in JSON, if If it returns true only if R is a prefix of R, then only parse R as JSON until R is generated. 开放 The subtree is sufficient to determine the string R 开放 Until it corresponds to the correct context in R.

[0342] Syntax with a unique key. Syntax for a given key value. In this case, we define a function to check the uniqueness of the key, denoted as In a given string In the case of another string k, if and only if there exists at most one that can be parsed as start k middle When the substring of s, because This means that in any parse tree of s, there exists at most one branch with a node key and an output k. Assume... For its input in syntax A function that returns true in the case of [condition]. If for all [conditions]... and all possible keys k, So let's talk about grammar. For key-value syntax with a unique key, that is, for all strings R, C:

[0343]

[0344] Specific two-stage parsing for unique key syntax. Assumptions This is based on the unique key syntax given above. We assume... For LL(1). This is the case for the grammar of interest, as described previously. General LL(1) parsing algorithms are known.

[0345] We consider a set of T pairs of context functions Instantiate it so that T contains the terms used for The allowed paths for paired strings in the string. We also allow... An auxiliary constraint is taken as input, wherein the auxiliary constraint is the key k( The output R 开放 The specified key in the tuple (T,k) is denoted as S and

[0346] Assumption By rule Where is used for The non-end of the generation rule, and for The start symbol in [the text]. We will [do something]. Defined as a function, the function determines whether string s is in In the input R, and if so, is the key in s equal to k? 开放 superior, (a) By running Check R 开放To check R by running the LL(1) parsing algorithm to resolve R with the valid key value pair (b) of key k, R is checked. 开放 Parse into key-value pairs in R.

[0347] Figure 14 Showing the functions In key value syntax Parse string R and search for specific key-value pairs R 开放 The generated instance pseudocode. Here, it will be used as a reference. The LPable hard-decoded LL(1) parsing table is obtained by...

[0348] To perform operations on a long string R To avoid the expensive computation, we introduce a transformation Trans to extract a substring R′ of R such that R′ = R according to the requirement. 开放 .

[0349] For strings s and t, we also define a function substring(s,t) that returns true when t is a substring of s, and a function equal to (s,t) that returns true when s = t. We define this using rules.

[0350]

[0351] and This means that whenever (R′, R) are equal, 开放 )hour And rules

[0352]

[0353] For all strings R′,S 开放 Both are valid.

[0354] Can be displayed. This is correct relative to R. More specifically, if R′ is a substring of R, then the key-value pair R... 开放 Depend on Analysis: Therefore, the same pair must be... The substring. (Attributed to) The global uniqueness of the key in the pair R means that only one such pair exists. 开放 and It must be true.

[0355] The additional protocol details above (similar to those described elsewhere in this document) are presented as illustrative examples only and are not intended to be limiting in any way. Other embodiments may utilize alternative protocol arrangements to implement the distributed oracles disclosed herein.

[0356] As indicated above, the illustrative embodiments of the distributed oracles disclosed herein can be implemented in a wide variety of different applications.

[0357] For example, DECOs can be used to implement personal data marketplaces, where users control and sell their personal data. It is well known that web services profit from the monetization of user data. Personal data marketplaces implemented using the techniques disclosed herein can undermine this data by enabling users to sell their data in an open market. In illustrative embodiments, DECOs are a key enabler for personal data marketplaces because they allow buyers to verify the origin and integrity of data from websites. DECOs also allow sellers to preprocess data, such as revising sensitive information for privacy protection while preventing seller fraud. Some implementations utilize DECOs to provide verifiable claims against price discrimination.

[0358] As another example, DECOs can be used to provide proof of financial solvency. As a more specific illustration of this type of arrangement, using a DECO, Alice could prove to Bob that she has a balance exceeding $5,000 in a particular bank. This simple proof demonstrates not only Alice's financial solvency but also her ability to open the account (e.g., that Alice is not on any sanctions list when the bank conducts an anti-money laundering (AML) screening). Importantly, DECOs protect Alice's privacy by revealing only that her balance is above $5,000, not her actual balance or identity.

[0359] As another example, DECOs can be used to provide proof of account ownership. In one illustration of this arrangement, a DECO can be used to anonymously prove ownership of an account (such as an email account, social media account, etc.). For instance, Alice could prove to Bob that she owns an email account ending in @example.org without revealing the account name. This proves Alice's connection to an organization, which is useful for things like whistleblowing or anonymous complaints.

[0360] Additional examples of applications of decentralized oracles disclosed herein include credential recovery and decentralized identity. As an example of the former, DECO allows users to prove their access to specific online resources, such as a Facebook account, in a privacy-preserving manner, avoiding the use of OAuth. This allows users to leverage existing services to prove their identity for purposes such as key recovery. As an example of the latter, DECO also allows users to prove, in a privacy-preserving manner, that they possess certain characteristics verified by a third-party provider (e.g., that they are over 18 years old). This is an example of what is also referred to herein as anonymous age verification. Such verification can be used to construct credentials in decentralized identity systems.

[0361] The aforementioned decentralized oracle applications are merely examples and should not be construed as limiting in any way. Additional details regarding implementation schemes for these and other example applications of decentralized oracles as disclosed herein can be found elsewhere in this document.

[0362] Suppose that communication between various components of an information processing system configured to implement one or more distributed oracles as disclosed herein occurs via one or more networks. Such networks may illustratively include, for example: global computer networks, such as the Internet, WAN, LAN, satellite networks, telephone or cable television networks; cellular networks, such as 3G, 4G or 5G networks; wireless networks implemented using wireless protocols such as Bluetooth, WiFi or WiMAX; or various portions or combinations of these and other types of communication networks.

[0363] A given processing device that implements at least a portion of the functionality of a distributed oracle as disclosed herein may include components such as a processor, memory, and a network interface. It is assumed that the processor is operatively coupled to memory and to the network interface. The memory stores software program code for execution by the processor when implementing the functional portion of the processing device.

[0364] It should be understood that this article combines... Figures 1 to 14 The specific arrangements shown and described are presented as illustrative examples only, and numerous alternative embodiments are possible. The various embodiments disclosed herein should therefore not be construed as limiting in any way. In other embodiments, numerous alternative arrangements for implementing distributed oracles may be utilized. For example, those skilled in the art will recognize that alternative processing operations and associated system entity configurations may be used in other embodiments. Therefore, it is possible that other embodiments may include additional or alternative system entities relative to the entities of the illustrative embodiments. Furthermore, in other embodiments, specific system and apparatus configurations and associated distributed oracles may vary.

[0365] It should also be noted that the information processing system arrangement described above is only exemplary, and alternative system arrangements may be used in other embodiments.

[0366] A given client, server, processor, or other component in the information processing system described herein is illustratively configured to utilize a corresponding processing device including a processor coupled to memory. The processor executes software program code stored in memory to control processing operations and other functionalities. The processing device also includes a network interface supporting communication via one or more networks.

[0367] Processors, in any combination, may include, for example, microprocessors, ASICs, FPGAs, CPUs, GPUs, ALUs, DSPs, or other similar processing device components, as well as other types and arrangements of processing circuitry systems. For example, at least a portion of the functionality of a distributed oracle provided by a given processing device as disclosed herein may be implemented using such a circuitry system.

[0368] Memory stores software program code for execution by a processor in performing a functional part of a processing device. A given memory that stores such program code for execution by a corresponding processor is an example of the contents of a processor-readable storage medium having program code embodied therein, and may include, in any combination, electronic memory such as SRAM, DRAM, or other types of RAM, ROM, flash memory, magnetic memory, optical memory, or other types of storage devices.

[0369] Articles of manufacture including such processor-readable storage media are considered embodiments of the present invention. As used herein, the term "article of manufacture" should be understood to mean that it does not contain transient propagation signals.

[0370] In other embodiments, other types of computer program products, including processor-readable storage media, may be implemented.

[0371] Additionally, embodiments of the present invention may be implemented in the form of an integrated circuit, the integrated circuit including a processing circuit system configured to perform processing operations associated with a distributed oracle and other related functionalities.

[0372] The processing apparatus in the given embodiments may be in any combination including, for example, a laptop computer, tablet computer, or desktop personal computer, a mobile phone, or other types of computer or communication device. For example, a computer or mobile phone may be used as a processing apparatus for implementing at least a portion of the functionality associated with a distributed oracle as disclosed herein. These and other communications between various elements of an information processing system, including processing apparatus associated with corresponding system entities, may be conducted via one or more networks.

[0373] The information processing system disclosed herein may be implemented using one or more processing platforms or parts thereof.

[0374] For example, an illustrative embodiment of a processing platform that can be used to implement at least a portion of an information processing system includes a cloud infrastructure that includes virtual machines implemented using a hypermanager running on a physical infrastructure. Such virtual machines may include corresponding processing devices that communicate with each other via one or more networks.

[0375] In this embodiment, the cloud infrastructure may further include one or more sets of applications running on counterparts in virtual machines under the control of a super manager. Multiple super managers may also be used, each providing a set of virtual machines using at least one underlying physical machine. Different sets of virtual machines provided by one or more super managers can be utilized when configuring various instances of different components of the information processing system.

[0376] Another illustrative embodiment of a processing platform that can be used to implement at least a portion of the information processing system disclosed herein includes a plurality of processing devices communicating with each other via at least one network. It is assumed that each processing device of the processing platform includes a processor coupled to memory.

[0377] Similarly, these specific processing platforms are presented only as examples, and information processing systems may include additional or alternative processing platforms, as well as numerous different processing platforms in any combination, each of which includes one or more computers, servers, storage devices or other processing devices.

[0378] For example, other processing platforms used to implement embodiments of the present invention may include virtualization infrastructure that replaces virtualization infrastructure including virtual machines, or different types of virtualization infrastructure other than virtualization infrastructure including virtual machines. Therefore, in some embodiments, it is possible that system components may run at least partially in cloud infrastructure or other types of virtualization infrastructure, including virtualization infrastructure using Docker containers or other types of Linux containers implemented using operating system-level virtualization based on Linux control groups or other similar mechanisms.

[0379] Therefore, it should be understood that in other embodiments, different arrangements of additional or alternative elements may be used. At least a subset of these elements may be implemented together on a common processing platform, or each such element may be implemented on a separate processing platform.

[0380] Furthermore, numerous other arrangements of computers, servers, storage devices, or other components are possible in an information processing system. These components can communicate with other elements of the information processing system via any type of network or other communication medium.

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

[0382] The specific configuration of the information processing system described herein is merely exemplary, and such a system may include, in other embodiments, elements other than those specifically shown or in place of those specifically shown, including one or more elements of the type commonly found in conventional implementations of such systems.

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

[0384] Therefore, the techniques described in some embodiments herein in the context of providing a distributed oracle for TLS can be adapted directly for use in other contexts. Thus, the illustrative embodiments of the invention should not be construed as being limited to TLS or its associated processing context.

[0385] It should also be understood that the specific process steps used in the embodiments described herein are merely exemplary, and other embodiments may utilize different types and arrangements of processing operations. For example, certain process steps shown as being performed sequentially in the illustrative embodiments may be performed at least partially in parallel with each other in other embodiments.

[0386] It should be emphasized again that the embodiments of the invention described herein are intended to be illustrative only. Other embodiments of the invention may be implemented using information processing systems, networks, and devices of different types and arrangements than those used in the specific illustrative embodiments described herein and in numerous alternative processing contexts. Furthermore, certain assumptions made herein in the context of describing certain embodiments do not need to apply in other embodiments. These and numerous other alternative embodiments will be readily apparent to those skilled in the art.

Claims

1. An information processing system, comprising: A verifier device, comprising a processor coupled to a memory; The verifier device is configured to communicate with client devices and server devices via one or more networks; The verifier device is further configured to: Participating in a three-way handshake protocol with the client device and the server device, wherein the verifier device and the client device obtain a corresponding sharing of session keys for a secure session with the server device; Receive submissions related to the secure session of the server device from the client device; In response to receiving the submission, additional information related to the secure session that was previously inaccessible to the client device is released to the client device; and The correctness of at least one representation of the data obtained by the client device from the server device as part of the secure session is verified, at least in part, based on the submission and the additional information.

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

3. The information processing system according to claim 1, wherein the validator device comprises a specific oracle node from a set of oracle nodes in a distributed oracle system.

4. The information processing system according to claim 1, wherein the verifier device includes a distributed verifier device, wherein the functionality of the verifier device spans multiple dissimilar processing devices.

5. The information processing system according to claim 1, wherein the server device includes a server device having transport layer security functions and the security session includes a transport layer security session.

6. The information processing system of claim 1, wherein the submission associated with the secure session includes the submission of query response data obtained by the client device from the server device as part of the secure session.

7. The information processing system of claim 1, wherein the submission in relation to the secure session includes the submission of a prover key established by the client device in conjunction with the three-way handshake protocol but previously inaccessible to the verifier device.

8. The information processing system of claim 1, wherein the additional information released to the client device in response to receiving the submission includes a validator key established by the validator device in conjunction with the three-way handshake protocol but previously inaccessible to the client device.

9. The information processing system of claim 1, wherein the verifier device is further configured to operate as a proxy for the client device in conjunction with the interaction between the client device and the server device, such 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.

10. The information processing system of claim 1, wherein the verifier device is further configured to receive from the client device one or more statements representing the data obtained by the client device from the server device as part of the secure session.

11. The information processing system of claim 10, wherein one of the one or more statements includes a substring selectively revealed as part of the query response data obtained by the client device from the server device as part of the secure session.

12. The information processing system of claim 10, wherein a given one of the one or more statements is configured to provide context integrity by utilizing a multi-stage resolution protocol, in which query response data obtained by the client device from the server device as part of the secure session is preprocessed by the client device to produce reduced data, which is then parsed by the client device in conjunction with the generation of the given statement to be sent by the client device to the validator device.

13. The information processing system of claim 1, wherein, in conjunction with the three-way handshake protocol, the client device and the verifier device jointly establish one or more shared session keys with the server device, wherein the client device has a first shared key of a given one of the one or more shared session keys, the verifier device has a second shared key of the given shared session key, and the server device has a composite session key combining the first shared key and the second shared key.

14. The information processing system of claim 1, wherein, in conjunction with the three-way handshake protocol, the client device receives from the server device an encryption key that is inaccessible by the verifier device.

15. The information processing system of claim 1, wherein the verifier device and the client device cooperate using a corresponding sharing of the session key of their secure session with the server device to generate a query provided by the client device to the server device, requesting the server device to send the data to the client device.

16. The information processing system of claim 15, wherein the verifier device and the client device cooperate using a corresponding sharing of the session key of their secure session with the server device to verify the response provided to the client device by the server device in response to the query.

17. The information processing system according to claim 1, wherein, in conjunction with the three-way handshake protocol, the client device and the verifier device establish a corresponding prover and verifier key.

18. The information processing system of claim 17, wherein verifying the correctness of at least one representation of data obtained by the client device from the server device as part of the secure session comprises verifying a proof provided by the client device to the verifier device, wherein the proof is generated by the client device based at least in part on: (i) the verifier key established by the client device in conjunction with the three-way handshake protocol; (ii) The verifier key established by the verifier device in conjunction with the three-way handshake protocol; (iii) The secret information of the client device.

19. The information processing system of claim 1, wherein verifying the correctness of at least one representation of data obtained by the client device from the server device as part of the secure session comprises: Obtain data derived from at least a portion of at least one ciphertext from the secure session; and The client device verifies the correctness of at least one representation of the data.

20. A method performed by a validator device configured to communicate with a client device and a server device via one or more networks, the method comprising: Participating in a three-way handshake protocol with the client device and the server device, wherein the verifier device and the client device obtain a corresponding sharing of session keys for a secure session with the server device; Receive submissions related to the secure session of the server device from the client device; In response to receiving the submission, additional information related to the secure session that was previously inaccessible to the client device is released to the client device; and The correctness of at least one representation of the data obtained by the client device from the server device as part of the secure session is verified, at least in part, based on the submission and the additional information. The verifier device for performing the method includes a processor coupled to a memory.

21. The method of claim 20, wherein verifying the correctness of at least one representation of data obtained by the client device from the server device as part of the secure session comprises: Obtain data derived from at least a portion of at least one ciphertext from the secure session; and The client device verifies the correctness of at least one representation of the data.

22. The method of claim 20, wherein the verifier device is further configured to operate as a proxy for the client device in conjunction with the interaction between the client device and the server device, such that the verifier device automatically obtains, via the verifier device operating as the proxy, the ciphertext exchanged between the client device and the server device as part of the secure session.

23. A computer program product comprising a non-transitory processor-readable storage medium, wherein program code of one or more software programs is stored therein, wherein the program code, when executed by a validator device configured to communicate with a client device and a server device via one or more networks, causes the validator device to perform the following operations: the validator device includes a processor coupled to memory. Participating in a three-way handshake protocol with the client device and the server device, wherein the verifier device and the client device obtain a corresponding sharing of session keys for a secure session with the server device; Receive submissions related to the secure session of the server device from the client device; In response to receiving the submission, additional information related to the secure session that was previously inaccessible to the client device is released to the client device; and The correctness of at least one representation of the data obtained by the client device from the server device as part of the secure session is verified, at least in part, based on the submission and the additional information.

24. The computer program product of claim 23, wherein verifying the correctness of at least one representation of data obtained by the client device from the server device as part of the secure session comprises: Obtain data derived from at least a portion of at least one ciphertext from the secure session; and The client device verifies the correctness of at least one representation of the data.

25. The computer program product of claim 23, wherein the verifier device is further configured to operate as a proxy for the client device in conjunction with the interaction between the client device and the server device, such that the verifier device automatically obtains, via the verifier device operating as the proxy, the ciphertext exchanged between the client device and the server device as part of the secure session.

Images