Decentralized technologies for transport layer security and data validation in other contexts.

Abstract

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

Description

[Technical Field]

[0001] Cross-reference of related applications This application claims priority to U.S. Provisional Patent Application No. 62 / 894,052, “DECO: Decentralized Oracles for TLS,” filed on 30 August 2019, which is incorporated herein by reference in its entirety.

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

[0003] This field generally concerns information security, including, for example, techniques for proving that data originates from a specific source, or, alternatively, techniques for verifying the accuracy of data obtained in the context of Transport Layer Security (TLS) and other contexts. [Background technology]

[0004] Thanks to the widespread deployment of TLS, users can access private data through channels with end-to-end confidentiality and integrity. However, what users cannot do is prove to third parties the origin of such data—that is, that it truly originates from a particular website. Existing methods either introduce undesirable trust assumptions or require server-side modifications. As a result, the value of a user's private data is trapped at its source. [Overview of the project]

[0005] An exemplary embodiment provides a decentralized oracle for TLS and numerous other applications where it is necessary or otherwise desirable to prove that data originates from a specific source.

[0006] For example, some embodiments overcome the aforementioned shortcomings of existing methods by providing a decentralized oracle, exemplified herein called a DECO, which allows users to prove that portions of data accessed via TLS originate from a specific website, and optionally, prove statements about such data with zero knowledge, thereby keeping the data itself confidential. Thus, a DECO can free data from centralized web service silos and make this data accessible to a wide range of applications. Advantageously, a DECO in an exemplary embodiment works without the need for trusted hardware or server-side modifications.

[0007] In one embodiment, the apparatus comprises a verifier device including a processor and memory coupled to the processor. The verifier device is configured to communicate with client devices and server devices over one or more networks. The verifier device participates in a three-way handshake protocol with the client devices and server devices, and the verifier device and client devices each obtain a share of the session key for a secure session with the server device. The verifier device receives a commitment from the client device related to the secure session with the server device, and in response to receiving the commitment, exposes to the client device additional information related to the secure session that was previously inaccessible to the client device. Based at least in part on the commitment and the additional information, the verifier device verifies the accuracy of at least one characterization of the data obtained by the client device from the server device as part of the secure session.

[0008] Please understand that the aforementioned configuration is merely an example, and numerous alternative configurations are possible.

[0009] These and other embodiments of the present invention include, but are not limited to, systems, methods, apparatus, processing devices, integrated circuits, and processor-readable storage media in which software program code is internally embodied. [Brief explanation of the drawing]

[0010] [Figure 1] This document illustrates an information processing system that implements a decentralized oracle for TLS in an exemplary embodiment. [Figure 2] This is a flowchart of the process for implementing a decentralized oracle for TLS in an exemplary embodiment. [Figure 3] An example of the functionality of a decentralized oracle in an exemplary embodiment is shown. [Figure 4] This illustrates multiple stages of device interaction in a decentralized oracle implementation comprising a server device, a certificate device, and a verifier device in an exemplary embodiment. [Figure 5] The following is an example of data, including bank statement information, used to demonstrate selective disclosure and contextual integrity attacks in an exemplary embodiment. [Figure 6] A detailed diagram of one possible implementation of a decentralized oracle protocol in an exemplary embodiment is shown. [Figure 7] A detailed example of a three-party handshake protocol used when implementing a decentralized oracle in an exemplary embodiment is provided. [Figure 8] This illustrates the protocol executed between the certificater device and the verifier device when establishing key sharing in an exemplary embodiment. [Figure 9] An example of additional protocols used in conjunction with the implementation of a distributed oracle in an exemplary embodiment is shown. [Figure 10]An example of additional protocols used in conjunction with the implementation of a distributed oracle in an exemplary embodiment is shown. [Figure 11] This example illustrates a two-party smart contract where one of the parties uses a decentralized oracle to retrieve information provided to the smart contract. [Figure 12] The following shows exemplary data processed using the explicit and blacked-out modes of one or more decentralized oracles in an exemplary embodiment. [Figure 13] The following shows exemplary data processed using the explicit and blacked-out modes of one or more decentralized oracles in an exemplary embodiment. [Figure 14] The following is pseudocode for a two-stage parsing of a unique-key grammar in an exemplary embodiment. [Modes for carrying out the invention]

[0011] Embodiments of the present invention may be implemented, for example, in the form of an information processing system, including a computer network or other arrangements of a network, clients, servers, processing devices, and other components. Exemplary embodiments of such systems are described in detail herein. However, it should be understood that embodiments of the 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. Thus, the term “information processing system” as used herein is intended to be interpreted broadly to encompass these and other configurations.

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

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

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

[0015] Furthermore, while the exemplary embodiments herein utilize one or more servers of a specific type, such as TLS server 106, it should be recognized that other types of secure protocols can be used in other embodiments and implemented on other types of server devices. Therefore, the term “server device” as used herein is intended to be interpreted broadly and should not be considered in any way limited to TLS servers.

[0016] In some embodiments, the client device 102 acts as the respective certifier device to the certifier device 104 or another zero-knowledge proof (ZKP) oracle node 110 of System 100. Thus, the certifier device 104 may be considered a ZKP oracle node of System 100. Therefore, a given “certifier device,” as the term is widely used herein, may include, for example, a specific oracle node in a set of oracle nodes of a decentralized oracle system such as System 100.

[0017] The specific number, types, and arrangement of devices and other components in System 100 are presented as illustrative examples only and may vary in other embodiments. For example, while this embodiment shows only a single verifier device 104, other embodiments may include multiple verifier devices, such as in an arrangement where other ZKP oracle nodes 110 act as their respective verifier 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 decentralized oracle configurations are possible.

[0018] The verifier device 104 comprises a three-party handshake module 112, a post-handshake interaction module 114, and a proof verification module 116. These modules implement their respective individual protocols of the decentralized oracle protocol, also referred to herein as the DECO protocol, as will be described in more detail below.

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

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

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

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

[0023] A manufactured article comprising such a processor-readable storage medium is considered an embodiment of the present invention. The term “manufactured article” as used herein is understood to exclude transient propagated signals.

[0024] Other types of computer program products, including processor-readable storage media, can be implemented in other embodiments.

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

[0026] The network interface 124 is configured to allow the verifier device 104 to communicate with other system elements via the network 105 and may include one or more conventional transceivers.

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

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

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

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

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

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

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

[0034] In other embodiments, the verifier device 104 is further configured to act as a proxy to the client device 102-1 in conjunction with the interaction between the client device 102-1 and a given TLS server, thereby automatically obtaining ciphertext exchanged between the client device 102-1 and the given TLS server as part of a secure session via the verifier device 104 acting as a proxy. Such embodiments are referred to herein as “proxy mode” configurations.

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

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

[0037] As another example, a given statement of one or more is exemplary configured to provide contextual integrity through the use of a multi-stage parsing protocol, and as part of a secure session, query response data obtained by client device 102-1 from a given TLS server is preprocessed by client device 102-1 to generate reduced data that is subsequently parsed by client device 102-1, along with the generation of a given statement that is sent by client device 102-1 to verifier device 104.

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

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

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

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

[0042] The verifier device 104 and the client device 102-1 can similarly work together, using their respective shares of the session key for a secure session with a given TLS server, to respond to queries and verify the response provided to the client device 102-1 by the given TLS server.

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

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

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

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

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

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

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

[0050] In step 202, along with the three-party handshake protocol, the verifier and the certificater each obtain their respective shares of the session key for the secure session with the server.

[0051] In step 204, the verifier receives a commitment from the certificater related to a secure session with the server.

[0052] In step 206, in response to receiving the commitment, the Validator exposes to the Certifier additional information related to the secure session that was previously inaccessible to the Certifier.

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

[0054] Numerous other techniques can be used in connection with the implementation of decentralized oracles such as those disclosed herein.

[0055] Therefore, the specific processing operations and other functionalities described in conjunction with the flowchart in Figure 2 are presented only as illustrative examples and should not be construed as limiting the scope of the present invention in any way. Alternative embodiments may use other types of processing operations involving verifier devices, certifier devices, and server devices. For example, the order of process steps may be changed in other embodiments, or certain steps may be executed simultaneously with each other rather than sequentially. Alternatively, multiple instances of the process may be executed in parallel with each other within system 100 for different sets of certifiers, verifiers, and server devices. Thus, system 100 can implement a large number of decentralized oracles simultaneously using the techniques disclosed herein.

[0056] Further embodiments of the exemplary model are described below with reference to Figures 3 to 14.

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

[0058] As a result, users' private data remains locked away at its source. Users cannot export their data to other applications in an integrity-protected manner without the assistance and permission of the current data owner.

[0059] The exemplary embodiments herein address these and other problems by providing a technology called DECO (Decentralized Oracle). DECO allows a user to prove that data accessed via TLS originates from a specific website, and optionally proves statements about such data with zero knowledge, thereby keeping the data itself confidential. Advantageously, DECO in the exemplary embodiments can be implemented without requiring any trusted hardware or server-side modifications.

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

[0061] It should be noted that these and other references to DECO in this specification refer to exemplary embodiments and should not be construed as limiting any particular features, functionality, benefits, and other details of those embodiments in any way. Alternative embodiments may implement additional or alternative techniques for validating data sources in TLS and other contexts.

[0062] As described above, TLS is a strong and widely deployed protocol that allows users to access web data through a confidential and integrity-protected channel. However, TLS has a serious limitation: it does not allow users to prove to third parties that data they have accessed genuinely originated from a particular website. As a result, the use of the data is often limited to its source, reducing the user's right to data portability, a right recognized by recent regulations such as the GDPR.

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

[0064] To better understand this issue, consider the example of Alice wanting to prove to Bob that she is over 18 years old. Currently, age verification services require users to upload their ID and detailed personal information, which raises privacy concerns. However, various websites, such as company payroll records or the DMV website, generally store and provide verified dates of birth. Alice could send a screenshot of her date of birth from such a site, but this can be easily forged. Even if the screenshot is somehow proven to be authentic, information revealing not only that she is over 18 but also her exact date of birth would be leaked.

[0065] Oracles, initially proposed to prove the origin of online data against smart contracts, are a step towards exporting TLS-protected data to other systems with guarantees of origin and integrity. However, existing schemes have serious technical limitations. These existing schemes only work with deprecated TLS versions, do not provide privacy from the oracle (e.g., TLSNotary), or rely on trusted hardware (e.g., Town Crier), against which various attacks have recently emerged. Another class of oracle schemes presupposes server-side cooperation, requiring the server to install TLS extensions or modify application layer logic. Server-driven oracle schemes suffer from two fundamental problems. First, these schemes break legacy compatibility, creating significant barriers to widespread adoption. Moreover, such solutions only offer conditional exportability, as the web server has the sole decision-making power regarding which data can be exported and can arbitrarily censor export attempts. A mechanism that allows users to export any data they have access to would enable entire application hosts that are currently unattainable.

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

[0067] DECO makes rich internet data accessible with guaranteed authenticity and privacy for a wide range of applications, including applications that cannot access the internet, such as smart contracts. DECO has the potential to fundamentally shift today's web data dissemination models by providing options for private data delivery, transfer to third parties, or public release. This technological capability highlights potential legal and regulatory challenges in the future, but at the same time, it is expected to create and deliver compelling new services. Importantly, unlike some alternative methods, DECO does not require trusted hardware.

[0068] In some embodiments, at a high level, the certifier commits a data D to the verifier, and optionally a statement π about D, where D is a TLS server S. D To prove that it originates from [source]. Referring again to the example of proving age, statement π D The attribute "D=y / m / d is Alice's birthday, and the current date - D is at least 18 years old" is possible.

[0069] Informally, DECO achieves authenticity—that is, the verifier is only confident that the asserted statement about D is true and that D was actually obtained from the TLS server S. DECO also makes statements π for some D that the verifier obtained from S. D It provides privacy in the sense that it merely learns to persist.

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

[0071] To address this challenge, DECO introduces a novel three-party handshake protocol between the certificater, verifier, and web server that creates a non-forgeable commitment by the certificater to the verifier in a single TLS session data D. The verifier can then verify that D genuinely originates from the TLS server. From the certificater's perspective, the three-party handshake maintains the security of TLS in the presence of a malicious verifier.

[0072] Efficient selective disclosure. After committing to D, the prover proves a statement about the commitment. While any statement can theoretically be supported, it is optimized for what is likely to be the most common application to only explicitly reveal a substring of the response to the prover. Such statements are called selective disclosures. Granular selective disclosures allow users to conceal sensitive information and reduce the input length to subsequent proofs.

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

[0074] Contextual integrity. Selective disclosure allows a prover to reveal only a substring D' of the server's response D. However, the substring can mean different things depending on when it appears, and a malicious prover could mislead by quoting it out of context. Therefore, it is necessary to prove not only that D' appears in D, but also that D' appears in the assumed context, i.e., that D' has contextual integrity with respect to D (note that this is different from "contextual integrity" in privacy theory).

[0075] Contextual integrity attacks can be prevented if session content is structured and parsable. Fortunately, most web data adopts this format (e.g., JavaScript® Object Notation (JSON) or Hypertext Markup Language (HTML)). A comprehensive solution is to parse the entire session and prove that the explicitly stated parts belong to the required branch of the parse tree. However, under certain constraints generally met by web data, parsing the entire session is not essential. Several embodiments disclosed herein provide novel two-stage parsing schemes in which the prover preprocesses the session content and parses typically much smaller results. From the definition of program equivalence, as used in programming language theory, it is possible to construct a formal framework for inferring about the security of two-stage parsing schemes. The exemplary embodiments disclosed herein provide several practical implementations for specific grammars. These definitions and constructions can be generalized to other oracles, for example, to prevent a comprehensive version of content concealment attacks.

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

[0077] Experiments with these applications demonstrate that DECO is highly efficient. For example, for TLS 1.2 in a WAN configuration, the online time for performing a three-party handshake is 2.85 seconds, and for 2PC query execution, it is 2.52 seconds. Generating zero-knowledge proofs for the aforementioned applications takes approximately 3 to 13 seconds. More detailed information is provided elsewhere in this specification.

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

[0079] Furthermore, the following details a broad class of statements for TLS records that can be efficiently proven with zero knowledge using DECO. Such statements allow users to open only substrings of session data commits. The optimization achieves a significant efficiency improvement over comprehensive ZKP.

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

[0081] Transport Layer Security (TLS) Here, we provide some background information on the TLS handshake and record protocols built by DECO in exemplary embodiments.

[0082] TLS is a family of protocols that provide privacy and data integrity between two communication applications. Roughly speaking, this family consists of two protocols: the handshake protocol, which uses asymmetric cryptography to set up a session and establish shared client and server keys for the next protocol, the record protocol, in which data is transmitted with confidentiality and integrity protection using symmetric cryptography.

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

[0084] In an exemplary embodiment, DECO utilizes an elliptic curve Diffie-Hellmann (DH) key exchange with temporary secrets (ECDHE), but this is an example and not an limitation.

[0085] Record Protocol. In order to transmit application layer data (e.g., HTTP messages) over TLS, the Record Protocol first...

number

number

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

[0087] Multi-party calculation Each has several secrets i Party

number

number

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

[0089] Here, we describe the problems solved by an exemplary embodiment of DECO and present a high-level overview of its architecture.

[0090] Problem statement: Decentralized oracle Exemplary embodiments herein provide protocols for constructing an "oracle," an entity capable of proving the origin and characteristics of online data. The goal is to enable a certifier P to prove to a verifier V that a piece of data originates from a specific website S, optionally proving a statement about such data with zero knowledge, and keeping the data itself confidential. Accessing the data may require confidential input from P (e.g., a password), and such confidential information also needs to be kept confidential from V.

[0091] In an exemplary embodiment, we focus on a server running TLS, a widely deployed security protocol suite on the internet. However, TLS alone does not prove the origin of data. While TLS uses public-key signing for authentication, it also uses symmetric-key primitives to protect the integrity and confidentiality of exchanged messages using a shared session key established at the start of each session. Therefore, P, who knows this symmetric key, cannot prove to a third party any statement about cryptographically authenticated TLS data.

[0092] A web server itself can assume the role of an oracle, for example, simply by signing data. However, a server-driven oracle not only incurs high adoption costs but also puts users at a disadvantage, as the web server can impose arbitrary limitations on the oracle's capabilities. A scheme that allows anyone to prove the origin of the data they access, without relying on a single central control point like a web server providing the data, is of interest.

[0093] In an exemplary embodiment, these and other challenges are addressed by introducing what we call a “decentralized oracle,” which does not rely on coordination from trusted hardware or web servers. This problem is far more advanced than previous oracles because it goes beyond those earlier methods by supporting proof for arbitrary attributes of data, while eliminating solutions that require servers to modify oracle code, deploy new software, or use prediction markets.

[0094] Authenticated data feeds for smart contracts. A key application of the exemplary embodiments disclosed herein is the construction of authenticated data feeds (ADFs), i.e., data with verifiable origin and accuracy, for smart contracts. A wide variety of other applications are also supported by the technologies disclosed herein.

[0095] In the context of ADF, since smart contracts cannot participate in the 2PC protocol, smart contracts must rely on oracle nodes that participate as V on behalf of the oracle nodes. Therefore, in some embodiments, DECO is deployed in a decentralized oracle network, in which case a set of independently operating oracles is available for use by the smart contract. It should be noted that the oracles running DECO are trusted only for integrity, not for privacy. Smart contracts can further hedge against integrity flaws by querying multiple oracles and requiring, for example, majority vote consent. It should be emphasized that the privacy of DECO is maintained even if all oracles are compromised. Thus, DECO makes it possible to provide smart contracts with ADFs derived from private data while keeping private data confidential from the oracles.

[0096] Notation and Definitions In some embodiments, we use P to represent a prover, V to represent a verifier, and S to represent a TLS server. Boldface characters (e.g.,

Number

Number

[0097] As illustrated in Figure 3, the ideal functionality F Oracle is used to model the essential properties of an oracle. To separate the parallel execution of F Oracle , all messages are tagged with a unique session id denoted as sid. Additional or alternative oracle properties can be used in other embodiments.

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

[0099] P verified the query template and statement ("ok" and θ s After sending F Oracle This retrieves the response R from S using a constructed query from the template. Assuming an honest server, R is ground truth. Oracle It sends Stmt(R) and the data source to V.

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

number

[0101] Adversarial model and security characteristics. In an exemplary embodiment, consider a static, malicious network adversary A. A compromised party may arbitrarily deviate from the protocol and reveal the state of these parties to A. As a network adversary, A has the advantage that TLS does not conceal length, and therefore F Oracle The message length from is determined. P and V shall select and agree on appropriate queries (for example, these queries should be idempotent for most applications) and statements in accordance with the application layer protocol executed by S.

[0102] For a given query Q, the server's honest response is represented by S(Q). Security must persist if either P or V is compromised. Functionality F Oracle This reflects the following security guarantees:

[0103] • Proverb-Integrity: A malicious P cannot falsify the origin of the content, nor can it cause S to accept invalid queries or incorrectly respond to valid queries. Specifically, if the verifier takes (Query, Stmt) as input and outputs (b, S), then P has Q=Query(θ) in the TLS session. s You must send ) to S and receive a response R=S(Q) such that b=Stmt(R).

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

[0105] • Privacy: A malicious V can only obtain public information (Query, S) and evaluations of Stmt(R).

[0106] Substitution protocol In exemplary embodiments, we focus on two widely used representative TLS cipher suites: CBC-HMAC and AES-GCM. The technique is similarly generalizable to other ciphers (e.g., Chacha20-Poly1305). We will first illustrate a specific embodiment using CBC-HMAC, and then describe the technique for AES-GCM later.

[0107] TLS uses separate keys for each direction of communication. Unless explicitly specified, it uses k without distinguishing between the two. Enc and k MAC The session key is represented using the following method.

[0108] When presenting exemplary embodiments of DECO, we will start with a substitution protocol and build it step by step up to the complete protocol.

[0109] F between (P,V) OracleThe substitution protocol that achieves this is as follows: P queries server S and retrieves all messages sent to the server and all messages received from the server, respectively.

number

number

number

number

[0110] Next, with zero knowledge, 1) each

number

number

number

number

[0111] She also,

number

number

number

[0112]

number

number

number

number

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

number

number

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

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

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

[0117] Figure 4 shows an exemplary DECO implementation in an exemplary embodiment, comprising a server device, a certificate device, and a verifier device. In this embodiment, DECO is implemented as a three-phase protocol. The first phase is a novel three-party handshake protocol in which the certificate P, the verifier V, and the TLS server S establish a session key that is secretly shared between P and V. The handshake is a query execution phase in which P accesses the server according to the standard TLS protocol, but with the assistance of V. After P commits to the query and response, V reveals her key share. Finally, P certifies the statement regarding the response in the certificate generation phase.

[0118] Three-party handshake. Essentially, P and V act jointly as TLS clients. P and V negotiate a shared session key with S in a secret-sharing form. It should be emphasized that this phase, like the rest of DECO, is completely transparent to S and requires no server-side modifications.

[0119] Regarding the CBC-HMAC cipher suite, at the end of the three-party handshake, P and V each

number

number

number

[0120] The three-party handshake makes the aforementioned session data commitment non-forgery, as follows: At the end of the session, P initially as before

number

number

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

[0122] Query execution. As mentioned, since the session key is secretly shared, P and V execute an interactive protocol to construct a TLS message that encrypts the query. P then sends the message to S as a standard TLS client. For CBC-HMAC, P and V calculate the MAC tag of the query, while GCM performs authenticated encryption. Note that the query is confidential to P and should not be leaked to V. For comprehensive 2PC, it is expensive for large queries, so instead, a custom 2PC protocol is introduced that is more efficient in terms of order of magnitude than the comprehensive solution, as described elsewhere in this specification.

[0123] As explained earlier, before P receives V's key share, session data

number

[0124] Proof generation. In a non-forgerable commitment, P is the commitment.

number

number

[0125] however,

number

number

[0126] Instead, DECO introduces two techniques to support efficient proof of a broad, general class of statements, which are referred to herein as “selective disclosure” of TLS session transcripts. Selective disclosure involves either explicitly revealing a substring to V or blacking it out, i.e., deleting the substring and hiding it from V.

[0127] Figure 5 shows a simplified JSON bank statement for user Bob acting as a certificater, as an illustrative example. This example is used to demonstrate selective disclosure and contextual integrity attacks. Suppose Bob (P) wants to disclose his checking account balance to V. It would be undesirable to disclose his TLS session decryption key, which would also disclose his entire statement, including his transaction. Instead, using the techniques disclosed herein, Bob can efficiently disclose only the substrings from lines 5 through 7. Alternatively, if he is willing to disclose his savings account balance, he may black out his transaction from line 7 onward.

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

[0129] However, selective disclosure alone is insufficient for many uses. This is because the context of a substring influences its meaning. Without something called contextual integrity, P could disclose a substring that appears to be misleading, thus proving a claim against V. For example, Bob might not have a balance of more than $1,000. However, after looking at a bank statement, he could post a message to customer service in the same TLS session with the substring "balance": $5,000, and then (in the form of a reflection attack) reflect his pending message. He could then disclose this substring to the foolish V.

[0130] Various sanitization heuristics regarding input to V supplied by the prover, such as truncation of the session transcript, may potentially prevent some such attacks, but like input sanitization in other forms of web applications, they are vulnerable and susceptible to attacks.

[0131] Instead, we introduce a rigorous technique for explicitly and confidentially parsing session data. We call this technique "zero-knowledge two-stage parsing." According to this technique, P in the first stage

number

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

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

[0134] Figure 7 shows the formal specification of the three-party handshake protocol in an exemplary embodiment.

[0135] Figure 8 shows an exemplary ECtF protocol, which is part of a three-party handshake protocol in several embodiments.

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

[0137] Similar to the standard TLS handshake, the 3P-HS involves two steps: First, P and V compute additive shares of a secret that is shared with the server through a TLS-compatible key exchange protocol

Number

[0138] Step 1: Key exchange.

Number

[0139] The prover P starts the handshake by sending a regular TLS handshake request and a random nonce r c to S (in a ClientHello message). When receiving the certificate, the server nonce r s , and the signed temporary DH public key Y S = s S ·G from S (in Server-Hello and ServerKeyExchange messages), P checks the certificate and signature and forwards them to V. After performing the same checks, V computes the secret sV Sample the DH public key Y V =s V G sent her part to P, and then P sent another secret. P The DH public key Y is sampled and combined P =s P · G+Y V Send to S.

[0140] Since server S is running standard TLS, S will use the DH secret, Z=s S ·Y P· P (and V) gives Z its share of Z P =s P ·Y S (and Z V =s V ·Y S The calculation is performed as follows: Note that Z = Z P + Z V And + is,

number

[0141] Step 2: Key Derivation. Since P and V have established an additive share of Z (in the form of EC points), P and V proceed to derive the session key by evaluating the TLS-PRF keyed at the x-coordinate of Z.

[0142] The technical challenge here is arithmetic operations (i.e.,

number

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

number

number

number

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

number

number

Number

Number

Number

Number

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

Number

Number

Number

[0147] The second component is share multiplication: Given [α] and [b], we compute [αb]. [αb] can be computed using MtA as follows: Party i performs MtA to compute α1, α2 such that α1 + α2 = α1·b2 + α2·b2. Then party i is m i =α i +α i ·y i It outputs [the following]. The security and accuracy of the protocol can be discussed in the same manner as above.

[0148] Secure evaluation of TLS-PRF. By calculating the so-called premaster secret of TLS in ECtF, with the x-coordinate share of Z, P and V are used to evaluate TLS-PRF in 2PC to derive the session key. Using a known SHA-256 circuit, the TLS handshake circuit is manually optimized, resulting in a total AND circuit complexity of 779,213.

[0149] Adaptation to support GCM. GCM uses a single key for both encryption and MAC (for each direction). Adapting the above protocol to support GCM in TLS 1.2 is straightforward. Because GCM keys are shorter, the first step will remain the same, while the output of the second step will need to be truncated.

[0150] Adaptation to TLS 1.3. To support TLS 1.3, the 3P-HS protocol must be adapted to the new handshake flow and different key derivation circuit. In particular, all handshake messages after ServerHello are encrypted here. In a naive strategy, they would be decrypted on 2PC, which would be costly because certificates are usually large. However, thanks to the key independence characteristics of TLS 1.3, it is possible to construct a 3P-HS protocol with the same complexity as in TLS 1.2, as described elsewhere in this specification.

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

[0152] First, we will focus on a one-round session where P sends all queries to S before receiving any response. Most DECO applications, such as proving the origin of content retrieved via HTTP GET, are one-round. Extending DECO to support multi-round sessions will be described elsewhere in this specification.

[0153] CBC-HMAC. It should be noted that P holds the encryption key while P and V hold shares of the MAC key. To construct a TLS record to encrypt Q, which is potentially private to P, the two parties first perform the 2PC protocol to compute the HMAC tag τ of Q, and then P encrypts Q||τ locally and sends the ciphertext to S.

[0154] H represents SHA-256. Recall that the HMAC of message m using key k is as follows:

number

[0155] The terms ipad and opad represent the respective "internal" and "external" values ​​used in the HMAC algorithm. Since 2PC requires hashing the entire query and calculating the internal hash, a direct 2PC implementation would be expensive for large queries. This is advantageously avoided in the exemplary embodiment by calculating the internal hash locally (i.e., without 2PC) for P.

number

number

[0156] This optimization utilizes the Merkle-Damgard structure of SHA-256. It assumes that m1 and m2 are two blocks of the correct size. Then,

number

number

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

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

number

[0159] AES-GCM. For GCM, P and V perform authenticated encryption of Q. 2PC-AES is straightforward in optimized circuitry, but is expensive because computing tags for large queries involves evaluating long polynomials in a large field for each record. The optimized protocol performs local polynomial evaluation by pre-computation, as described in more detail elsewhere in this specification. Because 2PC-GCM involves AES encryption as well as tagging, it results in higher computational costs and latency than CBC-HMAC.

[0160] Other embodiments disclosed herein utilize a highly efficient alternative protocol called a proxy mode protocol, which completely circumvents the post-handshake 2PC protocol, having additional trust assumptions.

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

[0162] To clarify, the details of the zero-knowledge proof are given in the ideal functionality F. ZK Abstracting with F ZK It sends w and the relation π(x,w)∈{0,1} (defined below) to V. Specifically, for CBC-HMAC, x, w, and π are defined as follows:

number

number

number

number

[0163] Assuming the functionality of secure 2PC and ZKP, the Prot example shown in Figure 6 DECO F in Figure 3 is used against malicious adversaries. Oracle This demonstrates that it can be implemented securely through UC (Unified Communications).

[0164] More specifically, in the group used in the three-party handshake, the individual logging problem is difficult, and assuming that f (the SHA-256 compression function) is a random oracle, Prot DECO (F 2PC F ZK ) Hybrid World F Oracle This will be implemented securely through UC.

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

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

[0167] Unlike CBC-HMAC, GCM is not committed: for a given ciphertext C encrypted with key k, a person who knows k can efficiently find a k’≠k that decrypts C into a different plaintext while passing the integrity check. To prevent such attacks, P needs to commit her key share k before learning V's key share. In the proof generation phase, in addition to proving statements about Q and R, P needs to prove that the session key used to decrypt P and

Number

Number

[0168] Proof Generation Recall that the prover P commits to the ciphertext of the TLS session

Number

Number

Number

Number

[0169]

number

number

[0170] The following explanation presents two classes of statements optimized for illustrative applications: explicitly revealing only the substrings of a response while proving their origin ("selective disclosure"), or further proving that the revealed substrings appear in the context assumed by V ("contextual completeness through two-stage parsing").

[0171] Selective disclosure. An exemplary embodiment implements a technique referred to herein as “selective disclosure,” which enables P to efficiently reveal or black out substrings within the plaintext. The plaintext record is chunked

number

number

number

number

number

[0172] CBC-HMAC. For proof generation, P is the cryptographic key k. Enc and MAC key k MAC V holds both, while MAC key k MAC Please note that only the plaintext record is retained. This performance assumes a cipher suite using SHA-256 and AES-128, which is consistent with this implementation, but these techniques are applicable to other parameters. Please note that post-MAC encryption is used: plaintext record

number

number

number

number

number

number

number

[0173] Explicit TLS record.

number

number

[0174] By leveraging the post-MAC encryption structure, the same thing can be done with ZKP using only three AES calls. This means that

number

number

number

number

number

[0175] Disclosure of records with blackened blocks. Assume that the i-th block contains confidential information that P wants to blacken. The direct strategy is,

Number

Number

Number

Number

[0176] This is expensive because it involves 3 AES and 256 SHA-256 compressions in ZKP.

[0177] Utilizing the Merkle-Damgard structure of SHA-256 enables some optimizations. Let f represent the compression function of SHA-256, and s i-1 denote,

Number

Number

Number

number

number

[0178] On the other hand, s i-1 and s i If it is not possible to explicitly specify both to V (for example, B i If a brute-force attack against it is possible, Block B i The cost can still be reduced by blacking out the prefix (or suffix) of records containing P. The cost incurred thereafter is 256-i SHA-2 hashes in ZKP. Additional details are provided elsewhere in this specification. In general, since the ZKP cost is proportional to the record size, TLS fragmentation can also reduce the cost by a constant factor.

[0179] Suffix blacked out. Suffix

number

number

number

number

number

number

[0180] Prefix is ​​blacked out. P calculates two ZKPs: 1)

number

number

number

[0181] Please note that blacking out prefixes / suffixes is only meaningful if the explicitly specified portion does not contain private user data. Otherwise, P would need to find the smallest substring containing all sensitive blocks and black out one of the prefixes / suffixes as described above.

[0182] GCM. Unlike CBC-HMAC, explicitly identifying blocks is very efficient in GCM. First, P explicitly identifies AES(k,IV) and AES(k,0) with proof of correctness in ZK, allowing V to verify the integrity of the ciphertext. Then, to explicitly identify the i-th block, P identifies the i-th counter C with proof of correctness. i =AES(k,inc i (IV)) merely explicitly specifies encryption.

number

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

[0184] Contextual completeness through two-stage parsing. For many applications, the verifier V may need to verify that explicitly stated substrings appear in the correct context. This property is called "contextual completeness." Below, we present techniques for V to specify the context and the secret methods for P to efficiently prove contextual completeness.

[0185] For the sake of clarity, this explanation will first focus on explicit mode, i.e., where P explicitly specifies a substring of the server's response to V. Then, we will describe blacked-out mode.

[0186] Context specification. This technique for specifying context assumes that the TLS-protected data transmitted to a given server S has a clearly defined context-free grammar G known to both P and V. In a slight abuse of notation, G represents both the grammar and the language specified by the grammar. Thus, R∈G represents a string R in this language given by G. G is unambiguous, i.e., all R∈G have a uniquely associated parse tree T R It shall have the following characteristics. JSON and HTML are examples of two widely used languages ​​that meet these requirements and are the focus here.

[0187] Next, P receives some substrings of response R from S. open When presenting R open If V is generated in a specific way assumed by V, then R open It is said that it has context completeness. Specifically, V is a valid substring R in R. open Specify a set S of locations where it is conceivable to see ρ. In this definition, S is the set of paths from the root of the parse tree defined by G to its internal nodes. Thus, s∈S, called allowed paths, are non-terminal sequences. R So, T R Represents the root of the (R parsing tree in G). R However, the leaves are string R open If there is a subtree that gives rise to (i.e., concatenates to form) it, then string R open It has contextual completeness with respect to (R,S), and ρ R This means that there exists a path s∈S from the root of the subtree.

[0188] Formally, attribute CTX G Contextual completeness is defined from this perspective. More specifically, the grammar G, R∈G, and substring R of R in the TLS response. open Given a set of allowed paths S,

number

number

number

number

number

number

[0189] Refer again to the example in Figure 5 and consider the JSON string J according to that example. JSON (roughly) includes the following rules: [Table 1]

[0190] In that example, V is a pair ρ with the key "checking a / c". checking A pair of keys ρ within an object given by the value of the key "balance" balance I was interested in learning how to derive these. Each of these non-terminals is an analytic tree T J These are the labels of the nodes within T. J From the start of the route ρ checking The path to get there is: Start → Object → Pairs * →ρ checkingWe need to traverse a sequence of nodes in this format, and here, Pairs * represents a sequence of zero or more pairs. Therefore, S is a set of such sequences, and R is a set of pairs. open This is the string "checking a / c". {"balance":$2000}.

[0191] Two-stage parsing. Generally, without explicitly specifying R, open The fact that it has contextual completeness, that is

number

[0192] Based on this observation, R open To efficiently calculate and

number

number

number

number

[0193] This protocol makes zero-knowledge computation significantly less expensive by deferring actual parsing for unverifiable computations. In other words,

number

number

number

[0194] The accuracy conditions for two-stage parsing are formalized by the operational semantic rules given below. Here, (f,σ) represents applying the function f to the input σ,

number

[0195] Grammar G, context functions, and allowed paths CTX G(S,·,·), transformation Trans, grammar G'={R':R'=Trans(R),R'∈G}, context function and allowed path CTX G’ (S',·,·), and the function cons G,G’ Given R'∈G, all (R,R',R open Regarding ), if Boolean b holds the following rule, (cons G,G’ S') says that S is correct.

number

[0196] Key-value grammar. A wide range of data formats, such as JSON, have the concept of key-value pairs. Therefore, they are the focus in some embodiments of DECO.

[0197] A key-value grammar G generates key-value pairs according to the rule "pair → start key intermediate value end", where the start, middle, and end are delimiters. For such a grammar, an array of optimizations can greatly reduce the complexity required to prove the context. Such optimizations are discussed below, with further details provided elsewhere in this specification.

[0198] Explicit for globally unique keys. For a key-value grammar G, a set of paths S is a substring R that satisfies context completeness for R∈G. open However, R open However, if it is required to be parsed as a key-value pair with a globally unique key K, then R open P is simply a substring of R and needs to be correctly parsed as a pair. Specifically, Trans(R) outputs a substring R' of R containing the desired key, i.e., a substring of the form "start K intermediate value end", and P is R open =R' can be output. G’If is the starting symbol in the generation rule of G', then rule S G’ →It can be defined by pairs. Next, (1)cons G,G’ (R,R') Check that R' is a substring of R, (2) S' = {S G’ Regarding}, CTX G '(S',R',R open ) is (a) R'∈G' and (b) R open Check that =R'. A globally unique key arises in several applications herein, such as when selectively disclosing responses to age.

[0199] Blacking out in key-value grammar. Therefore, this explanation of two-stage parsing assumes that P is a substring R of R. open This is explicitly stated for V, and R open This assumes explicit mode, where we prove that has context completeness with respect to the set of allowed paths specified by V. In blacked-out mode, the process is similar, but R open Instead of clearly and explicitly stating it, P uses the aforementioned technique to R open By generating a commitment to and replacing its position with a dummy character, for example, R open Remove the underscore and explicitly specify R.

[0200] application The DECO disclosed herein can be used in any oracle-based application. To illustrate the versatility of this DECO, three exemplary applications that leverage its various capabilities were implemented and evaluated: 1) confidential financial instruments implemented by smart contracts; 2) conversion of legacy credentials to anonymous credentials; and 3) price discrimination reporting with privacy preservation.

[0201] Confidential financial instruments. Financial derivatives are one of the most commonly cited smart contract applications, illustrating the need for authenticated data feeds (e.g., stock prices). For example, a popular financial instrument that is easy to implement in smart contracts is binary options. This involves the price P of several assets N at the end of a specified future time, e.g., day D. * If it is equal to or greater than a predetermined target price P, i.e., P * This is a contract between two parties betting whether P is greater than or equal to P. A smart contract implementing this binary option can call an oracle O to determine the outcome.

[0202] In principle, O can hide the underlying asset N and target price P of a binary option on the chain. O simply accepts the option details off-chain, resulting in Stmt := P * Only the bits specifying ≥?P are reported. This technique is called Mixicle.

[0203] A fundamental limitation of building a Mixicle is that O itself knows the details of the financial instrument. Before DECO, only oracle services using a Trusted Execution Environment (TEE) could hide queries from O. Here, we show how DECO can support binary options execution without knowing the details of the financial instrument, i.e., N or P. In this regard, note that the attribute direction ≥? or ≤? can be randomized. Also, the identification of winners and losers and the payment amounts can be hidden. Additional steps can be taken to hide other metadata, such as the exact settlement time.

[0204] In this exemplary application, the optional winner takes the role of P and receives the signed result of the Stmt from O, who takes the role of V. The protocol and its implementation are described below.

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

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

[0207] The binary options process illustrated in Figure 11 includes the following steps: 1) Setup: Alice and Bob agree on the binary option {N,P,D} and identifier ID SC Create a smart contract SC that has the addresses of the parties and evidence known to both parties, option {C N ,C P ,C D This includes a commitment to}. They also have a public parameter θ. P We will also agree on (for example, the URL for retrieving asset prices).

[0208] 2) Settlement: Assume Alice wins the bet. To claim payment, she uses DECO to generate a ZKP where the extracted current asset price matches her position. Alice and O run the DECO protocol (with O acting as a validator) and θ P Extract asset prices from (target URL). The response is (N * ,P * ,D * ) shall be included. Starting point θ P In addition to the ZKP in DECO to prove this, Alice proves the following statement:

number

[0209] If the proof verification is successful, the oracle will provide the contract ID.

number

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

[0211] As shown above, Figure 11 illustrates a request and response for the stock price API. The user (P) must also explicitly state a sufficient portion of the HTTP GET request to the oracle (V) to convince it of access to the correct API endpoint. The GET request includes several parameters to be explicitly stated, such as the API endpoint, and other parameters that have sensitive details, such as the stock name, and a private API key. P blacks out the sensitive parameters using the techniques disclosed herein and explicitly states the rest to V. The API key provides sufficient entropy to prevent V from knowing the sensitive parameters. However, without taking additional care, a malicious P could conceal their wrongdoing by altering the semantics of the GET request and blacking out the extra parameters. To guarantee that this does not happen, P must prove that the delimiters "&" and "=" do not appear in the blacked-out text.

[0212]

number

number

number

[0213] This two-stage parsing is secure, assuming that the key is unique and that the key "05.price" is followed by the price, and as mentioned above, the grammar of this response is a key-value grammar with a unique key. Similarly, P proves that the stock names and dates contained in R match the commitment. In the CBC-HMAC cipher suite, the zero-knowledge proof circuit involves blacking out the entire record (408 bytes), calculating the commitment, and string processing.

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

number

number

number

number

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

[0216] Figure 12 shows an example of this application, where credentials (demographic details) stored on the university website are used to prove that the student is 18 years of age or older. The student can provide this proof of age to any third party, such as the state issuing their driver's license or the hospital requesting consent for a medical examination. This example is implemented using the AES-GCM cryptographic suite and two-stage parsing with optimization based on a unique key.

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

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

[0219] However, in the United States, the FTC prohibits price discrimination if it leads to harm to competition, while newer privacy-focused laws in Europe, such as the GDPR, are once again focusing on the legality of this practice. In any case, consumers generally dislike being subjected to price discrimination. However, currently there is no reliable way for users to report price discrimination online.

[0220] Figure 13 illustrates an example of this application, where DECO enables a buyer to make a verifiable claim of perceived price discrimination by proving that the advertised price of a product is above a threshold, while concealing sensitive information such as names and addresses. This example is implemented using the AES-GCM cipher suite, suitable for TLS sessions, and explicitly displays 24 AES blocks containing the required order details and request URL.

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

[0222] Implementation methods and evaluation This section describes the implementation details and evaluation results of DECO and the three applications.

[0223] Three-party handshake and query execution. The TLS 1.2 three-party handshake protocol (3P-HS) and query execution protocols (2PC-HMAC and 2PC-GCM) were implemented in approximately 4700 lines of C++ code. A manually optimized TLS-PRF circuit with a total AND complexity of 779,213 was constructed. Modifications of known AES circuits were also used. This implementation uses Relic for the paillier cryptosystem and the EMP toolkit for the malicious-proof 2PC protocol.

[0224] To build an end-to-end system, the three-party handshake protocol and the 2PC-HMAC protocol were integrated with mbedTLS, a popular TLS implementation. 2PC-GCM can also be integrated into TLS, as well as with more engineering effort. The performance of 2PC-GCM was evaluated separately. The impact of the integration on performance should be negligible. 3P-HS was not implemented for TLS 1.3, but given the similar circuit complexity, the performance should be equivalent to that of TLS 1.2.

[0225] DECO performance was evaluated in both LAN and WAN configurations. Both the certifier and verifier run on c5.2xlarge AWS nodes with 8 vCPU cores and 16GB of RAM. The two nodes were located in the same region (but different availability zones) for the LAN configuration, but in two separate data centers (Ohio and Oregon) for the WAN configuration. The round-trip times between the two nodes in the LAN and WAN were approximately 1ms and 67ms, respectively, with a bandwidth of approximately 1Gbps.

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

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

[0228] In WAN configurations, execution time is dominated by network latency because MPC involves multiple round-trip communications. Nevertheless, performance remains acceptable, given that DECO is likely to be used regularly in most applications considered.

[0229] Proof generation. Zero-knowledge proofs were instantiated using libsnark's standard proof system. Efficiently provable statement templates were devised, but DECO users need to adapt these templates to specific applications. The SNARK compiler enables such adaptations in a high-level language, hiding low-level details from the developer. Statement templates and libsnark-compatible circuits were constructed using xjsnark and its Java®-like high-level language.

[0230] The reason for selecting libsnark is its relatively mature tooling support. The proofs generated by libsnark are of a consistent size and are very efficient to verify; the drawback is the need for a reliable setup for each circuit. DECO can be adapted to use, for example, Bulletproof, which does not require a reliable setup but has a large proof and verification time.

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

[0232] Table 2 below summarizes the results. The mean and its standard error were calculated using 50 samples. By using efficient statement templates and two-stage parsing, DECO achieves very practical proving performance. Proverber time is negligible due to libsnark's optimization for low verification overhead. The number of constraints (and proverber time) is highest for binary-option applications, due to extra string parsing routines. Multiple proofs are used in each application to reduce peak memory usage. For the most complex application, memory usage is 1.78 GB. Since libsnark proofs are a constant size of 287 B, the size of the proofs shown is a multiple of that. [Table 3]

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

[0234] In comparison, Town Crier runs a similar application using TEE in about 0.6 seconds, which is about 20 times faster than DECO, but with the added assumption of trust. Given that DECO is likely to be used only periodically in most applications, the overhead of DECO in achieving cryptographic strength security assurance seems reasonable.

[0235] Legal and compliance issues While users may have already extracted their data from the website, DECO allows users to export data along with a certificate of integrity without their explicit authorization or even awareness. Here, we will briefly discuss the resulting legal and compliance considerations.

[0236] However, and this is crucial, DECO users cannot unilaterally export their data to third parties with any guarantee of integrity, and rely on Oracle as a verifier for this purpose. DECO keeps user data private, but Oracle knows the websites and data types that users access. Therefore, Oracle can enforce appropriate data usage, for example, by rejecting transactions that may result in copyright infringement.

[0237] Both the user and the oracle are legally responsible for the data they access. However, recent case law under the Computer Fraud and Abuse Prevention Act (CFAA) has indicated a shift away from the criminalization of web scraping, with federal courts ruling that violating a website's terms of service is not a criminal act in itself. Users and oracles who violate a website's terms of service (such as "clickwrap") instead face civil penalties. Whether DECO complies with the terms of service of a given site is a site-specific and application-specific issue.

[0238] Oracles have an incentive to establish themselves as trusted entities within smart contracts and other ecosystems. A reputable Oracle will offer users a menu of specific certificates issued by the Oracle and target websites permitted by the Oracle, with the expectation that they will scrutinize these options to maximize security, minimize liability, and, if necessary, notify or cooperate with the target server.

[0239] The legal, performance, and compliance implications of false certificates based on incorrect data are also significant. However, these issues are not unique to DECOs, given the complex multi-site data dependencies of current internet services. Oracle services already rely on multiple data sources that help ensure accuracy. Oracle services in general have the potential to ultimately create infrastructure for certificates, including online checking and revocation capabilities, as well as different layers of security.

[0240] DECO in the exemplary embodiments disclosed herein is a privacy-preserving, decentralized oracle scheme for the latest TLS versions that does not require trusted hardware or server-side modifications. DECO enables a certificater to generate an unforgeable commitment to a TLS session and efficiently certify statements about session content. Several embodiments utilize a novel two-stage parsing scheme to mitigate context integrity attacks that are common to privacy-preserving oracles. DECO can free data from centralized web service silos and make this data accessible to a wide range of applications. The utility of DECO is demonstrated herein through fully functional implementations, along with three exemplary applications.

[0241] GCM protocol details GCM is authenticated encryption that uses additional data (AEAD) encryption. To encrypt, GCM encryption uses tuples.

number

number

[0242] The ciphertext is calculated in counter mode:

number

[0243] tag

number

number

number

number

number

number

number

number

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

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

[0246] Query execution Tag creation / validation. Calculating or validating GCM tags involves evaluating the above formula (1) in 2PC. The challenge is that formula (1) is an arithmetic calculation (e.g.,

number

number

number

[0247] This protocol eliminates the need for polynomial evaluation. The actual 2PC protocol involves only binary operations and can therefore be performed on a single circuit. Furthermore, the calculation per record is reduced to only one call to 2PC-AES.

[0248] This means that at the start of the session, in the preprocessing phase {h i This is achieved by calculating the share of {h} (in the 2PC protocol). The preprocessing overhead is amortized over the entire session because the same h is used for all subsequent records. i If there is a share of}, then P and V are the shares of polynomial evaluation.

number

number

[0249] The key point is that V never responds to the same IV multiple times; otherwise, P would know h. Specifically, in each response, V,

number

number

number

[0250] Record encryption / decryption. If the tags are properly checked, record decryption is straightforward. P and V simply compute the AES encryption of inc'(IV) using 2PC-AES. A minor caveat is that V must check that the counter to be encrypted has not been previously used as IV. Otherwise, P will know h for P in the manner outlined above.

[0251] Proof generation Block designation. P is AES block B. i However, we want to convince V that it is the i-th block of the encrypted record rec. The proof strategy is as follows: 1) AES block B i is the ciphertext block

number

[0252] A much more efficient proof is achieved by allowing P to explicitly provide V with two encrypted messages, AES(k,IV) and AES(k,0), and thus allowing V to verify the tag (see equation (1)). P only needs to prove the accuracy of the encryption with ZK and prove that the key used corresponds to the commitment, which requires two AES and one SHA-2 (P achieves a much more efficient proof by explicitly providing the hash of the key k P(Commit to this). Therefore, the total cost is three AES and one SHA-2 in ZKP.

[0253] Explicit TLS records. Proof techniques are a simple extension of the above case. P explicits the entire record rec, proving correct AES encryption for all AES blocks, resulting in a total of 514 AES and 1 SHA-2 in ZKP.

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

[0255] Protocol extension Adaptation to TLS 1.3 support. To support TLS 1.3, the 3P-HS protocol must be adapted to the new handshake flow and different key derivation circuit. In particular, all handshake messages after ServerHello are encrypted here. In a naive strategy, they would be decrypted on 2PC, which would be costly because certificates are usually large. However, thanks to the key independence property of TLS 1.3, P and V can securely reveal the handshake encryption key without affecting the secrecy of the final session key. The handshake integrity is preserved because the completed message authenticates the handshake using yet another independent key.

[0256] Therefore, the optimized 3P-HS works as follows: P and V perform the same ECDHE as before. They then derive the handshake key and application key by performing 2PC-HKDF, and explicitly provide the handshake key to P, allowing P to decrypt the handshake message locally (i.e., without 2PC). The 2PC circuit involves approximately 30 calls to SHA-256, totaling approximately 70k AND gates, comparable to that of TLS 1.2. Finally, since CBC-HMAC is not supported by TLS 1.3, DECO can only be used in GCM mode.

[0257] Query construction is optional. For applications that constrain the response to a query, for example, by including a stock ticker along with the transaction price, the 2PC query construction protocol can be completely avoided. Because TLS uses separate keys for each direction of communication, the client-to-server key can be explicitly provided to the P after the handshake, allowing the P to query the server without interacting with the V.

[0258] Support for multi-round sessions. DECO can be extended to support multi-round sessions in which the P sends further queries in response to previous responses. After each round, the P verifies the MAC tag of the incoming response by performing the same 2PC protocol as above, since MAC verification and creation are symmetric. However, additional commitments are required to prevent the P from exploiting MAC verification to forge tags.

[0259] In TLS, different MAC keys are used for communication from the server to the client and from the client to the server. To support multi-round sessions, the P and V perform 2PC to verify the former's tag and create a fresh message tag for the latter. The previous description in this specification specified the protocol for creating (and verifying) MAC tags. Here, we discuss additional security considerations for multi-round sessions.

[0260] When checking the tags of messages sent from the server to the client, it must be ensured that P cannot forge the tags of messages that did not originate from the server. Suppose P wants to verify the tag T of message M. P is first asked to commit to T, and then P and V perform the 2PC protocol to calculate the tag T' of message M. P is asked to open a commitment to V, and if T≠T', V aborts the protocol. Since P does not know the MAC key, P cannot calculate the tags of messages that did not originate from the server and commit to them.

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

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

[0263] In this alternative configuration, the verifier V acts as a proxy between the certifier P and the TLS server S, i.e., P sends / receives messages to / from S through V. The modified flow of the DECO protocol is as follows: After the three-party handshake, P sends key share k P Commit to, and then V, k V This is explicitly stated for P. Therefore, P is, where session key k=k P +k V The whole thing is included. P uses k to continue the session with the server, so V records the proxy traffic. After the session ends, P proves that the statements about the recorded session are the same as before.

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

[0265] This section describes the security characteristics and network assumptions related to the proxy mode protocol. Since a malicious V cannot compromise the integrity and privacy of TLS, the verifier integrity and privacy characteristics are clear.

[0266] However, regarding the integrity of the certificate, it is necessary to ensure that the proxy can reliably connect to S throughout the entire session. First, the proxy must be able to verify that it is reliably connected to S. Furthermore, P, who knows the session key and therefore can modify the session content, cannot tamper with the messages transmitted between the proxy and S.

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

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

[0269] This alternative protocol represents a trade-off between performance and security. While highly efficient because it avoids intensive encryption after the handshake, it requires additional network assumptions and is therefore only tolerable against weaker network adversaries.

[0270] Key-value grammar and two-stage parsing Preparation and notation. A context-free grammar (CFG) is represented as G=(V,Σ,P,S), where V is a set of non-terminal symbols, Σ is a set of terminal symbols, and P:V→(V∪Σ). *is a set of generation rules, and S∈V is the start symbol. The generation rules of CFG are defined in standard notation, using "-" to represent a set of negatives and ".." to represent a range. For a string w, the parser determines whether w∈G by constructing a parse tree of w. The parse tree represents a set of generation rules that can be used later to extract semantics.

[0271] Key-value grammars. These are grammars that have the concept of key-value pairs. These grammars are of particular interest to DECO because most API calls and responses are actually key-value grammars.

[0272] G is said to be a key-value grammar if grammar H exists, so that any given s∈G, s∈H, and H can be defined by the following rule: S → object (S → object) Object → NoPairsString Open Pair Pairs Close Pair → Start Key Middle Value End Pairs → Pair Pairs|""(pairs→pair pairs|"") Key → Charms Value → String | Object String→Character String|“”(chars→char chars|””) Character → Unicode escaped | escape escaped | added characters (char → Unicode - escaped | escape escaped | addedChars) Special→Start Special|Middle Special|End Special (special→startSpecial|middleSpecial|endSpecial) Start → De-escaping s Start special (start→unescapeds (startSpecial) Intermediate → Unescaped m Intermediate special (middle → unescaped) m (Middle Special) End → Non-escaping e Ending special (end→unescaped) e (endSpecial) Escaped → Special | Escape | ...

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

[0274] Special characters, i.e., characters that have special meaning when parsing a grammar, and special non-terminal escapes are used to remove ambiguity during parsing. For example, in JSON, a key is parsed if it is preceded by an empty double quote ("") and followed by a double quote. If the key or value expression itself must contain double quotes, they must be preceded by a backslash (\), i.e., escaped. The above rules mean that non-terminal characters that are not escaped before special characters can be parsed as special characters. Therefore, we can proceed and assume that there is no ambiguity in the generation of key-value pairs. Thus, when a substring R' of string R in a key-value grammar G is parsed as a pair, R' must correspond to the pair in the parsing tree of R.

[0275] In the key-value grammar described above, an empty string cannot be derived in the middle; that is, a non-empty string must mark the middle in order to enable parsing the key from the value. However, an empty derivation is possible, since either the start or end only separates the value between one pair from the key of the next pair. Finally, in some embodiments, two-stage parsing for key-value grammars allows for selectively disclosed strings, R open Please note that this only considers possible routes that have the requirement that they correspond to pairs.

[0276] Two-stage parsing of locally unique keys. Many key-value grammars enforce key uniqueness within a certain range. For example, in JSON, a key can be considered unique within a JSON object, even if there may be duplicate keys between objects. Two-stage parsing for such grammars can be reduced to parsing substrings. Specifically, Trans extracts a contiguous substring R' from R so that it can correctly determine the range of pairs even within R'. For example, in JSON, cons is only used if R' is a prefix of R. G,G’ If (R,R') returns true, then R open Simply parsing R' as JSON until a subtree that produces the result is generated, the string R open This is sufficient to determine whether it corresponds to the correct context in R.

[0277] A grammar that uses a unique key. Given a key-value grammar G, u G We define a function that checks the uniqueness of a key, expressed as follows: Starting k, if there is at most one substring of s that can be parsed as an intermediate, then the string s∈G and another string k,u G (s,k) = true is given. Since s ∈ G, this means that in any parse tree of s, there exists at most one branch with a node key and a derivation k. Parser GLet be a function that returns true if the input is within grammar G. Grammar G is all possible keys k, u G (s,k) = true, i.e., for all strings R,C, we say that it is a key-value grammar with a unique key if the following conditions apply:

number

[0278] The context function CTX for setting T includes an allowed path to a pair of strings in U. U Instantiate it. In addition, CTX U However, as a supplementary constraint, key k(output R of P) open Allows taking the key specified by (T,k). The tuple (T,k) is S and CTX U (S,·,·)CTX U,S It is expressed as follows.

[0279] P, Rule S P →Assume that the grammar is given by pairs, where the pairs are non-terminal production rules for U and S P This is the starting symbol for P. Parser P,k Define this as a function that determines whether a string s exists in P, and if so, whether the key of s is equal to k. Input R, R open If there is a CTX U,S The following should be checked: (a)R open Parser P,k (b)R is a valid key-value pair having key k, obtained by executing this. open This parses R as key-value pairs by executing the LL(1) parsing algorithm.

[0280] Figure 14 shows the analysis of a string R in key-value grammar U and a specific key-value pair R.open Function CTX for searching for the generation of U,S An example of pseudocode for this is shown. Here, PTable, which is the LL(1) parsing table for U, is CTX U,S It is hardcoded.

[0281] CTX on a long string R U、S To avoid the expensive calculations, R'=R according to the requirements. open To extract the R' substring R' such that, we introduce the transformation Trans.

[0282] Furthermore, for strings s and t, we define a function substring(s,t) that returns true if t is a substring of s, and an equal(s,t) function that returns true if s=t. The following rules apply to cons. U,P :

number

number

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

[0284] The embodiments may utilize alternative protocol arrangements when implementing the decentralized oracle disclosed herein.

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

[0286] For example, DECO can be used to implement a personal data marketplace where users manage and sell their own personal data. It is well known that web services profit by monetizing user data. A personal data marketplace implemented using the technologies disclosed herein could disrupt this data monopoly by enabling users to sell their data on an open market. DECO is a key enabler of personal data marketplaces in exemplary embodiments because it allows buyers to verify the origin and integrity of data from websites. DECO also allows sellers to preprocess data, such as redacting sensitive information for privacy protection, while preventing sellers from engaging in fraudulent activities. In some implementations, DECO is used to provide verifiable claims against price discrimination.

[0287] As another example, a DECO can be used to provide proof of financial ability. A more concrete example of this type of arrangement is that using a DECO, Alice could prove to Bob that her balance in a particular bank account exceeds $5,000. This simple proof demonstrates not only Alice's financial ability but also her ability to open an account (for example, that Alice is not on a sanctions list when the bank conducts an anti-money laundering (AML) screening). Importantly, the DECO protects Alice's privacy by disclosing only the fact that her balance exceeds $5,000, and not the actual balance or identifying information.

[0288] As a further example, DECO can be used to provide proof of account ownership. In one such arrangement, DECO can be used to anonymously prove ownership of an account, such as an email account or a social media account. For example, Alice could prove to Bob that she owns an email account ending in @example.org without explicitly stating what the account name is. This proves that Alice belongs to a particular organization, which is useful, for example, for whistleblowing or anonymous complaints.

[0289] Additional examples of applications of the decentralized oracle disclosed herein include credential recovery and decentralized identity. As an example of the former, DECO could enable a user to prove, in a privacy-preserving manner that avoids the use of OAuth, that she has access to a specific web resource, such as a Facebook account. This would enable the user to prove her identity by leveraging existing services, for example, for key recovery. As an example of the latter, DECO could also enable a user to prove, in a privacy-preserving manner, that she possesses certain characteristics, such as those claimed by a third-party provider (e.g., that she is 18 years of age or older). This is an example of what is referred to herein as anonymous age verification. Such verification could be used to construct credentials in a decentralized identity system.

[0290] The decentralized oracle applications described herein are merely examples and should not be construed as limiting in any way. Additional details regarding implementations of these and other exemplary applications of decentralized oracles disclosed herein can be found elsewhere in this specification.

[0291] Communication between various elements of an information processing system configured to implement one or more decentralized oracles disclosed herein shall be conducted over one or more networks. A given such network may exemplify various parts or combinations of these and other types of communication networks, for example, the Internet, WAN, LAN, satellite network, telephone or cable network, cellular network such as 3G, 4G, or 5G network, wireless network implemented using wireless protocols such as Bluetooth, WiFi, or WiMAX.

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

[0293] It should be recognized that the specific configurations shown and described herein in conjunction with Figures 1 to 14 are presented merely as illustrative examples, and that numerous alternative embodiments are possible. Therefore, the various embodiments disclosed herein should not be construed as limiting in any way. Numerous alternative configurations for implementing a decentralized oracle can be utilized in other embodiments. For example, those skilled in the art will recognize that alternative processing behaviors and associated system entity configurations can be used in other embodiments. Thus, other embodiments may include additional or alternative system entities compared to the entities of the exemplary embodiments. Furthermore, the configuration of specific systems and devices, as well as the associated decentralized oracle, can be modified in other embodiments.

[0294] Furthermore, it should be noted that the above-described information processing system configuration is merely illustrative, and alternative system configurations may be used in other embodiments.

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

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

[0297] Memory stores software program code for execution by a processor when implementing a part of the functionality of a processing device. A given memory that stores such program code for execution by a corresponding processor is, more generally, an example of what is called a processor-readable storage medium in which the program code is internally embodied, and may comprise any combination of electronic memory such as SRAM, DRAM, or other types of RAM, ROM, flash memory, magnetic memory, optical memory, or other types of storage devices.

[0298] A manufactured article comprising such a processor-readable storage medium is considered an embodiment of the present invention. The term “manufactured article” as used herein is understood to exclude transient propagated signals.

[0299] Other types of computer program products, including processor-readable storage media, can be implemented in other embodiments.

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

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

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

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

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

[0305] Another exemplary embodiment of a processing platform that may be used to implement at least a portion of the information processing systems disclosed herein comprises a plurality of processing devices communicating with one another over at least one network. Each processing device of the processing platform comprises a processor coupled to memory.

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

[0307] For example, other processing platforms used to implement embodiments of the present invention may have different types of virtualization infrastructure instead of, or in addition to, virtualization infrastructure with virtual machines. Thus, in some embodiments, system components can operate at least partially on cloud infrastructure or other types of virtualization infrastructure, including virtualization infrastructure that utilizes Docker containers, or other types of Linux containers implemented using operating system-level virtualization based on Linux® control groups or other similar mechanisms.

[0308] 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 collectively on a common processing platform, or each such element may be implemented on a separate processing platform.

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

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

[0311] The specific configurations of the information processing systems described herein are illustrative only, and in other embodiments, a given system may include, in addition to or instead of specifically indicated, one or more elements of a type commonly found in conventional implementations of such systems.

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

[0313] Accordingly, the techniques exemplified in some embodiments herein in the context of providing a decentralized oracle for TLS can be directly adapted for use in other contexts. Therefore, the exemplary embodiments of the present invention are not to be considered limited to TLS or its associated processing context.

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

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

Claims

1. It is a device, A verifier device equipped with a processor coupled to memory, The verifier device is configured to communicate with client devices and server devices via one or more networks. The aforementioned verifier device The client device receives a ciphertext commitment related to a secure session with the server device, In response to receiving the commitment of the ciphertext, the client device is made public to the client device additional information related to the secure session that was previously inaccessible to the client device, Based at least in part on the commitment of the ciphertext, verify the accuracy of at least one characterization of the data acquired by the client device from the server device as part of the secure session. It is further configured to do the following: Verifying the accuracy involves processing at least one characterization of the data using the ciphertext commitment and the additional information disclosed to the client device by the verifier device in response to the receipt of the ciphertext commitment from the client device, The verifier device is further configured to act as a proxy to the client device in conjunction with the interaction between the client device and the server device, thereby automatically obtaining ciphertext exchanged between the client device and the server device as part of the secure session via the verifier device acting as a proxy. Device.

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

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

4. The apparatus according to claim 1, wherein the verifier device comprises a distributed verifier device in which the functionality of the verifier device is distributed across a plurality of individual processing devices.

5. The apparatus according to claim 1, wherein the server device comprises a transport layer security (TLS) compliant server device, and the secure session includes a TLS session.

6. The apparatus according to claim 1, wherein the commitment relating to the secure session includes a commitment to query response data obtained by the client device from the server device as part of the secure session.

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

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

9. The apparatus according to claim 8, wherein one of the one or more statements is configured to provide contextual integrity through the use of a multi-stage parsing protocol, and as part of the secure session, query response data obtained by the client device from the server device is preprocessed by the client device to generate reduced data which is subsequently parsed by the client device, in conjunction with the generation of the given statement which is sent by the client device to the verifier device.

10. As part of the secure session, verifying the accuracy of at least one characterization of the data acquired by the client device from the server device is necessary. Obtaining data derived from at least a portion of at least one ciphertext of the secure session, The client device verifies the accuracy of at least one characterization of the data. The apparatus according to claim 1, including the following:

11. A method performed by a verifier device configured to communicate with client devices and server devices over one or more networks, The client device receives a ciphertext commitment related to a secure session with the server device, In response to receiving the commitment of the ciphertext, the client device is made public to the client device additional information related to the secure session that was previously inaccessible to the client device, Based at least in part on the commitment of the ciphertext, verify the accuracy of at least one characterization of the data acquired by the client device from the server device as part of the secure session. Includes, Verifying the accuracy involves processing at least one characterization of the data using the ciphertext commitment and the additional information disclosed to the client device by the verifier device in response to the receipt of the ciphertext commitment from the client device, The verifier device that performs the above method comprises a processor coupled to memory, The verifier device is further configured to act as a proxy to the client device in conjunction with the interaction between the client device and the server device, thereby automatically obtaining ciphertext exchanged between the client device and the server device as part of the secure session via the verifier device acting as a proxy. method.

12. As part of the secure session, verifying the accuracy of at least one characterization of the data acquired by the client device from the server device is necessary. Obtaining data derived from at least a portion of at least one ciphertext of the secure session, The client device verifies the accuracy of at least one characterization of the data. The method according to claim 11, including the method described in claim 11.

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

14. The method according to claim 11, wherein the commitment relating to the secure session includes a commitment to query response data obtained by the client device from the server device as part of the secure session.

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

16. A non-temporary processor-readable storage medium that internally stores the program code of one or more software programs, and a verifier device configured to communicate with client devices and server devices via one or more networks, wherein when executed by the verifier device including a processor coupled to memory, the verifier device, The client device receives a ciphertext commitment related to a secure session with the server device, In response to receiving the commitment of the ciphertext, the client device is made public to the client device additional information related to the secure session that was previously inaccessible to the client device, Based at least in part on the commitment of the ciphertext, verify the accuracy of at least one characterization of the data acquired by the client device from the server device as part of the secure session. Have them do it, Verifying the accuracy involves processing at least one characterization of the data using the ciphertext commitment and the additional information disclosed to the client device by the verifier device in response to the receipt of the ciphertext commitment from the client device, The verifier device is further configured to act as a proxy to the client device in conjunction with the interaction between the client device and the server device, thereby automatically obtaining ciphertext exchanged between the client device and the server device as part of the secure session via the verifier device acting as a proxy. Non-temporary processor-readable storage medium.

17. As part of the secure session, verifying the accuracy of at least one characterization of the data acquired by the client device from the server device is necessary. Obtaining data derived from at least a portion of at least one ciphertext of the secure session, The client device verifies the accuracy of at least one characterization of the data. A non-temporary processor-readable storage medium according to claim 16, including the following:

18. The non-temporary processor-readable storage medium according to claim 16, wherein when the program code is executed by the verifier device, the verifier device initiates one or more automated actions in response to the verification of the accuracy of the at least one characterization of the data acquired from the server device by the client device.

19. The non-temporary processor-readable storage medium according to claim 16, wherein the commitment related to the secure session includes a commitment to query response data obtained by the client device from the server device as part of the secure session.

20. The non-temporary processor-readable storage medium according to claim 16, wherein when the program code is executed by the verifier device, the verifier device causes the client device to receive from the client device one or more statements characterizing the data obtained from the server device as part of the secure session.

Images