CN114946152A - Decentralized techniques for authenticating data in transport layer security and other contexts - Google Patents

Abstract

The verifier device in one embodiment is configured to communicate with the client device and the server device via one or more networks. The authenticator device participates in a three-way handshake protocol with the client device and the server device, wherein the authenticator device and the client device obtain respective shares of a session key for a secure session with the server device. The authenticator device receives a submission from the client device relating to the secure session of the server device and, in response to receiving the submission, releases additional information relating to the secure session previously inaccessible to the client device. The verifier device verifies correctness of at least one characterization of data obtained by the client device from the server device as part of the secure session based at least in part on the submission and the additional information.

Description

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

Cross Reference to Related Applications

The present application claims a file filed 2019 on 30/8 and titled "DECO: priority of U.S. provisional patent application No. 62/894,052 for a Decentralized propheter for TLS (DECO), which is incorporated herein by reference in its entirety.

Statement of government support

The invention was made with U.S. government support under grant numbers CNS-1514163, CNS-1564102, CNS-1704615 and CNS-1933655 of the National Science Foundation (NSF) and the ARO institute grant number W911NF 161-0145. The government has certain rights in the invention.

Technical Field

The art relates generally to information security, including, for example, techniques for attesting to the correctness of data from a particular source or otherwise verifying data obtained in the context of Transport Layer Security (TLS) and in other contexts.

Background

Thanks to the widespread deployment of TLS, users can access private data via a channel with end-to-end confidentiality and integrity. However, what the user cannot do is prove to a third party the provenance of such data, i.e. that it really came from a particular website. Existing approaches introduce undesirable trust assumptions or require server-side modifications. As a result, the value of the user's private data is locked in its point of origin.

Disclosure of Invention

The illustrative embodiments are directed to TLS and provide a decentralized oracle in numerous other applications where it is necessary or otherwise desirable to prove that data is coming from a particular source.

For example, some embodiments overcome the above-described disadvantages of existing methods by providing a decentralized prolog machine (illustratively referred to herein as DECO) that allows a user to prove that a piece of data accessed via TLS is from a particular web site, and optionally to prove statements about such data with zero knowledge, thereby keeping the data itself secret. The DECO can thus release data from the centralized network services repository, making it accessible to rich applications. Advantageously, the DECO in the illustrative embodiments operates without trusted hardware or server-side modifications.

In one embodiment, an apparatus includes a verifier device that includes a processor and a memory coupled to the processor. The verifier device is configured to communicate with the client device and the server device via one or more networks. The authenticator device participates in a three-way handshake protocol with the client device and the server device, where the authenticator device and the client device obtain respective shares of a session key for a secure session with the server device. The authenticator device receives a submission from the client device relating to a secure session of the server device and, in response to receiving the submission, releases additional information relating to the secure session previously inaccessible to the client device. The verifier device verifies correctness of at least one characterization of data obtained by the client device from the server device as part of the secure session based at least in part on the submission and the additional information.

It will be appreciated that the foregoing arrangement is merely an example, and that numerous alternative arrangements are possible.

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

Drawings

FIG. 1 shows an information processing system implementing a decentralized oracle for TLS in an illustrative embodiment.

Fig. 2 is a flow diagram of a process for implementing a decentralized oracle for TLS in an illustrative embodiment.

FIG. 3 shows an example of decentralized oracle functionality in an illustrative embodiment.

Figure 4 illustrates stages of device interaction in a decentralized oracle implementation including a server device, a prover device and a verifier device in an illustrative embodiment.

FIG. 5 shows example data including bank statement information for exposing selective opening and context integrity attacks in an illustrative embodiment.

FIG. 6 shows a detailed view of one possible implementation of a decentralized oracle protocol in an illustrative embodiment.

FIG. 7 shows a detailed example of a three-way handshake protocol for implementing a decentralized oracle in an illustrative embodiment.

FIG. 8 shows a protocol conducted between a prover device and a verifier device to establish key sharing in an illustrative embodiment.

Fig. 9 and 10 show additional examples of protocols utilized in connection with implementation of decentralized oracle in illustrative embodiments.

Fig. 11 shows an intelligent contract embodiment involving two parties in which one of the parties utilizes a decentralized oracle to obtain information provided to the intelligent contract.

Fig. 12 and 13 show example data processed using respective revealing and revision (readact) modes of one or more decentralized propheters in an illustrative embodiment.

FIG. 14 shows pseudo code for two-stage parsing of unique key syntax in an illustrative embodiment.

Detailed Description

Embodiments of the invention may be implemented, for example, in the form of an information handling system comprising a computer network or other arrangement of networks, clients, servers, processing devices, and other components. Illustrative 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 handling systems and associated networks, clients, servers, processing devices, or other components. Accordingly, the term "information handling system" as used herein is intended to be broadly construed to encompass these and other arrangements.

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

Network 105 may illustratively include, for example: a global computer network, such as the Internet, a Wide Area Network (WAN), a Local Area Network (LAN), a satellite network, a telephone or cable television network; cellular networks, such as 3G, 4G or 5G networks; wireless networks implemented using wireless protocols such as bluetooth, WiFi, or WiMAX, or various portions or combinations of these and other types of communication networks.

The system 100 further includes a plurality of TLS servers 106 associated with respective protected data sources 108. The TLS server 106 is illustratively configured to control access to its respective protected data source 108. At least a subset of the protected data sources 108 illustratively includes respective websites having HTTPS functions, where HTTPS refers to the secure hypertext transfer protocol, which is an extension of the hypertext transfer protocol (HTTP). It should be appreciated that a wide variety of additional or alternative data sources may be used in other embodiments. The protected data source 108 of the system 100 is protected in the sense that it is securely accessible through at least one of the TLS servers 106 via HTTPS. Other data sources need not be accessible in this particular manner, and additional or alternative access control mechanisms may be implemented, and/or may be publicly accessible using other types of security protocols.

Further, although the illustrative embodiments herein utilize a particular type of server or servers (e.g., TLS server 106), it should be appreciated that other types of security protocols may be used in other embodiments and may be implemented in other types of server devices. Thus, the term "server device" as used herein is intended to be broadly understood and should not be construed as being limited to TLS servers in any way.

In some embodiments, the client device 102 operates as a corresponding prover device with respect to the verifier device 104 or other Zero Knowledge Proof (ZKP) predictive machine node 110 of the system 100. Thus, the verifier device 104 may be considered a ZKP predictive engine node of the system 100. Thus, a given "validator device," as that term is used broadly herein, may comprise a particular prolog-tor node of a set of prolog-tor nodes, e.g., of a decentralized prolog-tor system (e.g., system 100).

The particular number, type, and arrangement of devices and other components in the system 100 are presented as illustrative examples only and may be varied in other embodiments. For example, although only a single verifier device 104 is shown in this embodiment, other embodiments may include multiple verifier devices, as in arrangements in which other ZKP predictive machine nodes 110 operate as respective verifier devices. Further, one or more of the TLS servers 106 may each be configured to control access to multiple ones of the protected data sources 108. Numerous other decentralized propheter arrangements are possible.

The verifier device 104 includes a three-way handshake module 112, a post-handshake interaction module 114, and a proof verification module 116. These modules implement respective different ones of the decentralized prolog protocols, also referred to herein as the DECO protocols, as described in more detail below.

In the present embodiment, the verifier device 104 further comprises a processor 120, a memory 122 and a network interface 124. It is assumed that processor 120 is operatively coupled to memory 122 and to network interface 124 via the simplified illustrative interconnect shown in the figures.

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 another similar processing device component, in any combination, as well as other types and arrangements of processing circuitry. At least a portion of the functionality of the decentralized oracle provided by a given processing device as disclosed herein may be implemented using such circuitry.

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

A given such memory, which stores such program code for execution by the corresponding processor, is an example of what is more generally referred to herein as a processor-readable storage medium having program code embodied therein, and may comprise, in any combination, other types of storage devices, such as electronic memory, e.g., SRAM, DRAM, or other types of random access memory, Read Only Memory (ROM), flash memory, magnetic memory, optical memory, or any combination.

Articles of manufacture that include such processor-readable storage media are considered embodiments of the invention. The term "article of manufacture" as used herein should be understood to not include a transitory propagating signal.

In other embodiments, other types of computer program products comprising a processor-readable storage medium may be implemented.

Additionally, embodiments of the invention may be implemented in the form of an integrated circuit that includes processing circuitry configured to implement processing operations associated with one or more of the client device 102, the verifier device 104, the TLS server 106, and other ZKP predictive machine nodes 110.

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.

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

The authenticator device 104 receives a submission from the client device 102-1 relating to a secure session for a given TLS server. In response to receiving the submission, the authenticator device 104 releases additional information related to the secure session previously inaccessible by the client device 102-1 to the client device 102-1. These operations related to commit are illustratively under the control of the post-handshake interaction module 114.

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

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

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

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

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

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

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

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

As another example, a given one of the one or more statements is illustratively configured to provide contextual integrity by utilizing a multi-phase resolution protocol in which query response data obtained by the client device 102-1 from a given TLS server as part of a secure session is pre-processed by the client device 102-1 to generate reduced data that is subsequently parsed by the client device 102-1 in connection with the generation of the given statement to be sent by the client device 102-1 to the verifier device 104.

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

In some embodiments, in conjunction with the three-way 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, wherein the client device 102-1 has a first share of a given one of the 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 share and the second share.

Additionally or alternatively, in conjunction with the three-way handshake protocol, the client device 102-1 receives an encryption key from a given TLS server that is not accessible by the authenticator device 104.

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

The authenticator device 104 and the client device 102-1 may cooperate using their respective shares of the session key for the secure session with the given TLS server to authenticate the response provided by the given TLS server to the client device 102-1 in response to the query.

In some embodiments, in conjunction with the three-way handshake protocol, the client device 102-1 and the verifier device 104 establish respective prover and verifier keys. In such an embodiment, verifying the correctness of at least one representation of data obtained by the client device 102-1 from a given TLS server as part of a secure session illustratively includes verifying the attestation provided by the client device 102-1 to the verifier device 104. The attestation is illustratively generated by the client device 102-1 based at least in part on: (i) a prover key established by the client device 102-1 in conjunction with a three-way handshake protocol; (ii) a verifier key established by the verifier device 104 in conjunction with a three-way handshake protocol; and (iii) secret information of the client device 102-1, such as a password or passcode.

In some embodiments, verifying the correctness of at least one representation of data obtained by the client device 102-1 from a given TLS server as part of a secure session illustratively comprises: obtaining data derived from at least a portion of at least one ciphertext of the secure session; and verifying, by the client device 102-1, correctness of the at least one representation of the data. The term "ciphertext," as used in this context and elsewhere herein, is intended to be broadly understood and should not be construed as requiring the use of any particular cryptographic protocol.

It should be appreciated that the particular arrangement of components and other system elements shown in fig. 1 and their associated processing operations as described above are presented merely as illustrative examples, and that numerous alternative embodiments are possible.

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

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

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

In step 200, the authenticator participates in a three-way handshake protocol with the client and server, where the client acts as an authenticator.

In step 202, in conjunction with the three-way handshake protocol, the authenticator and the prover obtain respective shares of the session key for the secure session with the server.

In step 204, the verifier receives a submission from the prover relating to a secure session of the server.

In step 206, in response to receiving the submission, the authenticator releases additional information to the prover related to the secure session that was previously inaccessible by the prover.

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

Numerous other techniques may be used in association with implementations of a decentralized oracle as disclosed herein.

Thus, the particular process operations and other functionality described in connection with the flowchart of FIG. 2 are presented merely as illustrative examples and should not be construed as limiting the scope of the invention in any way. Alternate embodiments may use other types of processing operations involving a verifier device, a prover device, and a server device. For example, the ordering of process steps may be varied in other embodiments, or certain steps may be performed concurrently with one another rather than sequentially. Furthermore, multiple instances of the process may be conducted in parallel with one another within the system 100 for different sets of respective provers, verifiers, and server devices. Thus, the system 100 can implement a large number of decentralized oracle machines simultaneously using the techniques disclosed herein.

Additional aspects of the illustrative embodiments will now be described with reference to fig. 3-14.

The widespread deployment of TLS allows users to access private data via a channel with end-to-end confidentiality and integrity. However, what the user cannot easily do under conventional practice is to prove to a third party the provenance of such data, i.e. that it really came from a particular website. Existing approaches introduce undesirable trust assumptions or require server-side modifications.

As a result, the user's private data is locked at its point of origin. Users cannot export their data to other applications in an integrity protected manner without assistance and permission from the current data holder.

Illustrative embodiments herein provide a technique known as DECO (an abbreviation for decentralized propheter) to address these and other issues. DECO allows a user to prove that a piece of data accessed via TLS is coming from a particular web site, and optionally a statement about such data with zero knowledge, thereby keeping the data itself secret. Advantageously, the DECO in the illustrative embodiments may be implemented without requiring trusted hardware or server-side modifications.

The DECO can release data from the centralized network services repository, making it accessible to rich applications. To demonstrate the efficacy of DECO, we implemented three applications that were difficult to achieve without DECO: the method includes the steps of using a private financial instrument of an intelligent contract, converting a legacy credential to an anonymous credential, and a verifiable statement to discriminate against prices.

It should be appreciated that these and other references to DECO herein refer to illustrative embodiments and that the particular features, functionality, advantages, and other details of those embodiments should not be construed as limiting in any way. Alternate embodiments may implement additional or alternate techniques for verifying data sources in TLS and other contexts.

As indicated above, TLS is a powerful, widely deployed protocol that allows users to access network data via a confidential, integrity-protected channel. However, TLS has serious limitations: it does not allow a user to prove to a third party that a piece of data she has visited actually came from a particular website. Thus, data usage is typically limited to its point of origin, thereby reducing data portability for users, which is the right to be confirmed by recent legislation (e.g., GDPR).

Specifically, when a user accesses data online via TLS, she cannot export it securely without assistance (and therefore permission) from the current data holder. Thus, large amounts of private data are locked, intentionally or unintentionally, in "deep nets", which are portions of the network that are not publicly accessible.

To better understand the problem, consider the example where Alice wants to prove to Bob that she is 18 years old. Currently, age verification services typically require users to upload IDs and detailed personal information, which raises privacy concerns. But various websites, such as corporate payment records or DMV websites, in principle store and serve verified birth dates. Alice may send a screenshot of her birth date from this site, but this is easily forged. Also, even if the screen shot could prove to be authentic in some way, information (revealing her exact date of birth) would be leaked, not only if she was 18 years old.

The predictive engine was originally proposed to prove the provenance of online data to smart contracts, a step towards exporting TLS-protected data to other systems with provenance and integrity guarantees. However, the existing solutions have serious technical limitations. It works only for obsolete TLS versions and does not provide privacy from the prediction engine (e.g. tlsnottary) or relies on trusted hardware (e.g. Town criser), for which various attacks have recently emerged. Another category of prophetic schemes assume server-side collaboration, entrusting the server to install TLS extensions or change application layer logic. The server-facilitated predictive engine approach suffers from two basic problems. First, it breaks traditional compatibility, resulting in a significant barrier to wider adoption. Furthermore, this solution only provides conditional exportability, since the web server has a unique discretionary right (sole discovery) to determine which data can be exported, and can review export attempts at will. A mechanism that allows a user to export whatever data they may access would enable many applications that are not currently available.

To address the above issues, illustrative embodiments disclosed herein provide an arrangement known as DECO, a decentralized oracle for TLS. Unlike the predictive engine approach, which requires per-site support, DECO is illustratively any site that is source agnostic and supports running standard TLS. Unlike solutions that rely on participation of a website, DECO does not require server-side collaboration. Thus, a single instance of DECO may enable anyone to be a speaker of any website.

DECO enables rich internet data to be accessed by a wide range of applications, including applications that do not have access to the internet, such as smart contracts, for authenticity and privacy assurance. DECO can radically change today's network data dissemination model by providing private data delivery with options to transmit to third parties or to publish. This technical capability highlights potential future legal and regulatory challenges, but also anticipates the creation and delivery of new services that are attractive. Importantly, unlike some alternative methods, DECO does not require trusted hardware.

In some embodiments, at a high level, the prover submits a block of data D and proves to the verifier that D is from the TLS server

And optionally submit a statement π about D _D . Referring again to the example demonstrating age, state π _D May assert that "D is Alice's date of birth and current date-D is at least 18 years".

Informally, DECO implements authenticity-the verifier is only validating that the statement about D is true and D is actually from the TLS server

Is only assured when obtained. DECO also provides privacy because the verifier only learns to state π _D To the slave

Some D obtained holds.

Designing a DECO with the required security and feasible capabilities introduces several important technical challenges while using traditional TLS-compatible primitives. One challenge stems from the fact that TLS produces symmetric encryption and authentication keys that are shared by the client (e.g., the prover in DECO) and the web server. Thus, the client can forge any TLS session data in the sense that the data is signed with a valid authentication key.

To address this challenge, the DECO introduces a novel three-way handshake protocol among the prover, the verifier, and the web server that creates an unforgeable submission by the prover to the verifier of a piece of TLS session data D. The verifier can check that D is truly coming from the TLS server. From the perspective of the prover, three-way handshaking maintains the security of TLS in the presence of a malicious verifier.

After submission to D, the prover proves statements about the submission. While theoretically any statement could be supported, we optimize for the most popular applications possible-only revealing the substring of the response to the verifier. We refer to this statement as selective opening. Fine-grained selective opening allows users to hide sensitive information and reduce the input length of subsequent proofs.

An immature solution would involve expensive verifiable decryption of TLS records using the universal zero knowledge proof of knowledge (ZKP), but the illustrative embodiments herein achieve magnitude-level efficiency improvements by utilizing the TLS record structure. For example, a straightforward implementation of verifiable decryption of TLS records would involve proof of correct execution of a circuit of 1024 AES calls with zero knowledge, whereas by utilizing the MAC-then-encryption (MAC-then-encrypt) structure of CBC-HMAC, the illustrative embodiments herein may achieve the same result with only 3AES calls.

Selective opening allows the prover to only reveal the substring D 'of the server's response D. However, substrings can mean different things depending on the time they occur, and malicious provers can cheat by breaking the sense of a chapter. We therefore need to prove not only that D 'appears in D, but also in the intended context, i.e. D' has contextual integrity with respect to D. (Note that this is different from "context completeness" in privacy theory.)

If the session content is structured and parsable, context integrity attacks can be prevented. Fortunately most network data takes this form (e.g., in JavaScript object notation (JSON) or hypertext markup language (HTML)). A common solution is to parse the entire session and prove that the disclosed part belongs to the necessary branches of the parse tree. However, under certain constraints that are typically met by network data, it is not necessary to parse the entire session. Some embodiments disclosed herein provide a novel two-phase parsing scheme in which the prover pre-processes the session content and only parses the typically much smaller results. We extract from the interpretation of the equivalent of the program as used in programming language theory to build a formal framework on the security of the two-phase parsing scheme. The illustrative embodiments disclosed herein provide several practical implementations for a particular syntax. Our definitions and constructs are generalized to other prophetics as well. For example, it may prevent a common form of content hiding attack.

With respect to implementation and evaluation of the illustrative embodiments, we designed and implemented DECO as a complete end-to-end system. To demonstrate the efficacy of the system, we implemented three applications: 1) maintaining a financial instrument using the confidentiality of the smart contract;

2) converting the legacy credential into an anonymous credential; and 3) verifiable statements against price discrimination.

Our experiments for these applications show that DECO is very effective. For example, for TLS1.2 in the WAN setting, the online time is 2.85s for a three-way handshake and 2.52s for 2PC query execution. For the application described above, it takes about 3s to 13s to produce a zero knowledge proof. More details are provided elsewhere herein.

The DECO as disclosed in connection with illustrative embodiments to be described in detail below advantageously provides a provable secure decentralized orable scheme. In some embodiments, the DECO provides a propheter solution for modern TLS versions that does not require trusted hardware or server-side modifications.

We also describe in detail below a broad category of statements of TLS records that can be effectively certified in zero knowledge using DECO. This statement allows the user to open only the substring of the session data submission. The optimization achieves substantial efficiency improvements over the universal ZKP.

With respect to contextual integrity attacks and mitigation, we identify a new class of contextual integrity attacks that are common to privacy preserving speakers, and we describe our mitigation methods that involve a novel and effective two-phase resolution scheme.

Transport Layer Security (TLS)

We now provide some context to the TLS handshake and recording protocol on which the DECO is built in the illustrative embodiment.

TLS is a series of protocols that provide privacy and data integrity between two communicating applications. Roughly speaking, it consists of two protocols: a handshake protocol that establishes a session using asymmetric cryptography, thereby establishing a shared client and server key for a next protocol; a protocol is recorded in which symmetric cryptography is used to protect the transmitted data with confidentiality and integrity.

In a handshake protocol, the server and client first agree on a set of cryptographic algorithms (also called a set of cryptographic procedures). They then authenticate each other (client authentication optional) and finally securely compute the shared secret to be used for the subsequent recording protocol.

In the illustrative embodiment, DECO utilizes elliptic curve Diffie-Hellman (DH) key exchange (ECDHE) with ephemeral secrets, but this is by way of example and not of limitation.

To transport application layer data (e.g., HTTP messages) in TLS, the recording protocol first segments the application data D into fixed-size plaintext records D ═ D (D) ₁ ,…,D _n ). Each record is typically padded to multiple blocks (e.g., 128 bits). The recording protocol then optionally compresses the data, applies the MAC, encrypts, and transmits the results. The received data is decrypted, verified, decompressed, reassembled, and then delivered to a higher level protocol. The particular cryptographic operation depends on the negotiated set of cryptographic programs. DECO supports advanced encryption standards in two common modes(AES) cipher: CBC-HMAC and GCM, wherein CBC-HMAC refers to cipher block chaining-hash-based message authentication code, and GCM refers to Galois/counter mode. Additional details regarding these and other aspects of TLS can be found, for example, in t.dierks and e.rescorla, "Transport Layer Security (TLS) protocol version 1.2," RFC 5246, 2008, which is incorporated herein by reference. Likewise, other protocols may be used in other embodiments.

In some embodiments herein, we focus on TLS1.2, and describe later how our technique is generalized to TLS 1.3. Here we briefly note the main difference between these two TLS versions. TLS 1.3 removes the support of traditional non-AEAD ciphers. The handshake flow has also been reconstructed. All handshake messages after ServerHello are now encrypted. Finally, different key derivation functions are used. Additional details can be found in e.recorla's "Transport Layer Security (TLS) protocol version 1.3," RFC 8446, 2018, which is incorporated herein by reference.

Multi-party computing

Considering groups of n parties

Each of which holds a number of secrets s _i . Secure multi-party computation (MPC) allows it to compute f(s) collectively without leaking any information other than the output of f _i ,…,s _n ) That is to say that,

to s _j≠i Nothing is known. The security of the MPC protocol typically considers an adversary who destroys t players and tries to learn the personal information of honest players. A two-way calculation (2PC) refers to the special case where n is 2 and t is 1.

There are two general approaches to the 2PC protocol. The scrambling circuit protocol encodes f as a boolean circuit, which is the most suitable method for bitwise operations (e.g., SHA-256). Other protocols utilize threshold secret sharing and are best suited for arithmetic operations. But in some embodiments the function we compute using 2PC includes both bitwise and arithmetic operations. We split it into two components and use an optimized scrambling circuit protocol for bitwise operations and a secret sharing based MtA protocol for arithmetic operations. Additional details regarding example optimized scrambler circuit protocols used in the illustrative embodiments may be found in "Authenticated scrambling and Efficient malicious security Two-Party computing" (Authenticated scrambling and Efficient malicious security Two-Party computing) "by Xiao Wang, Samuel Ranellucci, and Jonathan Katz in ACM CCS, 2017, which is incorporated herein by reference. Additional details regarding the example secret sharing based MtA protocol used in the illustrative embodiments can be found in "fast multiparty threshold ECDSA with fast trust setup" (ACM CCS, 2018 by Rosario Gennaro and Steven goldfefefder, which is incorporated herein by reference. These are merely examples, and other types of protocols may be used in other embodiments.

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

The problem statement: distributed pre-speaking machine

The illustrative embodiments herein provide a protocol for building a "predictive machine" (i.e., an entity that can prove the provenance and nature of online data). Targeting a proof of acceptance

Direction verifier

Proving that a piece of data came from a particular website

And optionally attesting to statements about such data with zero knowledge, thereby keeping the data itself secret. Access to data may be required from

And such private informationAll should be from

The secret is maintained.

We focus in the illustrative embodiment on the server running TLS, a widely deployed suite of security protocols on the internet. However, TLS alone does not prove data provenance. While TLS uses public key signatures for authentication, it uses symmetric key primitives to protect the integrity and confidentiality of the exchanged messages using a shared session key established at the beginning of each session. Thus, knowing this symmetric key

Statements about cryptographically authenticated TLS data cannot be certified to third parties.

The web server itself may assume the role of the predictive engine, for example by signing only the data. However, a server-facilitated predictive engine would not only incur high adoption costs, but also place the user at a disadvantage: the network server may impose any constraints on the predictive capabilities. We are interested in a scheme where anyone can prove the provenance of any data she can access without relying on a single central point of control (e.g., a web server providing the data).

We address these and other attacks in the illustrative embodiments by introducing what we call herein a "decentralized presbyker" that does not rely on trusted hardware or collaboration from a network server. The problem is much more challenging than previous predictors because it hinders solutions that require the server to modify its code or deploy new software or use a forecasted market, while at the same time going beyond these previous approaches by supporting arbitrary assertions of data.

An important application of the illustrative embodiments disclosed herein is in the construction of Authentication Data Feeds (ADFs), i.e., data with provenance and correctness that can be verified, for intelligent contracts. A wide variety of other applications are advantageously supported by the techniques disclosed herein.

In the context of ADFs, because smart contracts cannot participate in the 2PC protocol, they must rely on the predictor node to represent them as a proxy

And (4) participating. Thus, in some embodiments, we deploy DECO in a decentralized presidenter network, where a set of independently operating presidenters are available for use by the intelligent contract. It should be noted that a propheter running a DECO is trusted only for integrity and not for privacy. The smart contract may further hedge against integrity failures by querying multiple prediction machines and requiring, for example, most agreements. We emphasize that the privacy of the DECO is preserved even if all the predictive machines are cracked. Thus, DECO enables a user to provide ADFs derived from private data to smart contracts while hiding the private data from the predictive player.

Symbols and definitions

In some embodiments, we use

To refer to prover, use

To refer to a verifier and use

To refer to the TLS server. We use the bold letter (e.g., M) to refer to the vector and M _i To refer to the ith element in M.

We use the ideal functionality as illustrated in FIG. 3

To model the basic properties of the prediction machine. To is coming to

All messages are tagged with a unique session id, denoted sid. Additional or alternative embodiments may be usedPredicting the machine properties.

As indicated in fig. 3, in this embodiment,

accept from

Secret parameter theta of _s (e.g., password), Query template Query, and Query from

Statement Stmt. Querying a template for acquisition

Secret theta of _s And returns a complete query containing the query

Specified public parameters. The example Query template would be Query (θ) _s ) "GOOG stock price on 1/2020, with API key θ _s ". Proving device

The query sent to the server may later be proven to be well formed (i.e., built from the template) without revealing the secret. Stating Stmt is

It is desirable to evaluate the response of the server. As per the previous example, since the response R is a number, it is stated below that it will be compared to a threshold: stmt (R) ═ R > $1,000.

In that

Acknowledging the query template and statement (by sending "good" and θ) _s ) After that time, the user can use the device,

using construction from templatesFrom a query search

The response of (2). We assume a honest server, so R is the real data.

Sending Stmt (R) and data source to

We are interested in this embodiment in a decentralized oracle that does not require any server-side modifications or collaboration, i.e.,

the unmodified TLS protocol is followed. More particularly, the decentralized talker protocol for TLS is a three-way protocol

So that 1) Prot is realized

And 2)

Standard TLS, possibly together with application layer protocols.

In an illustrative embodiment, we consider a static malicious network adversary

The parties with the damage can deviate from the protocol at will and move to

Revealing its state. As a result of the network-opponent,

from

The message length is learned, since TLS does not hide the length. Let us assume that

And

according to the principle of

The running application layer protocol selects and agrees on the appropriate queries (e.g., which should be idempotent for most applications) and statements.

For a given query

By

Refers to the honest response of the server. We require when

Or

And when damaged, the safety is kept. Functionality

The following safety guarantees are reflected:

prover integrity: malicious intent

The inability to forge content to come out of the way, she cannot make

Accepting invalid queries or incorrectly replying to valid queries. Specifically, if the verifier inputs (Query, Stmt) and outputs

Then

Must already be in the TLS session

Is sent to

Thereby receiving a response

Such that b is stmt (r).

Malicious verifier integrity

Can not make

An incorrect response is received. In particular, if

Output (Q, R), then R must be server pair

Submitted queries

The response of (a), i.e.,

privacy: malicious intent

Learning only public information

And evaluation of Stmt (R).

Protocol for scarecrow (Strawman)

We focus in the illustrative embodiment on two widely used representative TLS cryptographic program groups: CBC-HMAC and AES-GCM. Our technique is also generalized to other ciphers (e.g., Chacha20-Poly1305, etc.). We initially use CBC-HMAC to illustrate certain embodiments, and later describe techniques for AES-GCM.

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

In presenting an illustrative embodiment of the DECO, we begin with the Rice Rollers protocol and gradually build up as a complete protocol.

To realize

In between

The protocol of (1) is as follows.

Query server

And records all messages sent to and received from the server in the server

And

in (1). Suppose that

And (k) ^MAC ,k ^Enc ) Is a session key.

She then proves with zero knowledge 1) each

Decipher as R _i ‖σ _i A plaintext record and a MAC tag; 2) for R _i Per MAC tag σ of _i For k ^MAC Carrying out verification; and 3) b where the required statement evaluates to response (i.e., b ═ stmt (r)). The use of a standard symbol is used,

computing

Lambda verification (k) ^MAc ,σ _i ,R _i )＝1∧Stmt(R)＝b}。

She also demonstrated

Is well formed into

As in the demonstration of p _q Are similar to each other, and will

Is sent to

In that

The prover integrity property seems to be maintained under the conditions of true transcription of TLS sessions. Intuitively speaking, the CBC-HMAC ciphertext is bound to the underlying plaintext, therefore

May be considered a secure submission of session data. That is, given

Can only be opened (i.e., decrypted and MAC checked) for unique messages. Binding property prevention

Opening to different messages except for an initial session with a server

Unfortunately, this intuition is deficient. The scarecrow protocol failed completely because it was not guaranteed

The authenticity of. Proving device

Has a session key, and as such she may include

Encryption of any of the messages.

Furthermore, zero knowledge proof

The construction is required to involve decrypting and hashing the entire transcript, which can be prohibitively expensive. In order to make the protocol feasible, we need to significantly reduce the cost.

General description of DECO

The key failure of the above scarecrow method is

The session key is learned before she submits to the session. In an illustrative embodiment of DECO, from

Withhold the MAC key until after her submission.

And server

The TLS session in between must still provide confidentiality and integrity. Furthermore, the protocol must not degrade performance below the requirements of TLS (e.g., trigger timeouts).

FIG. 4 shows an example DECO implementation in an illustrative embodiment that includes a server device, a prover device, and a verifier device. In this embodiment, DECO is implemented as a three-stage protocol. The first stage is the prover therein

Verifying device

And TLS server

Is built in

And with

A novel three-way handshake protocol with a secret shared session key between. After the handshake is a query execution phase during which,

following the standard TLS protocol but from

Access the server with the help of (1). In that

After submission to the query and the response,

revealing her key sharing. Finally, the process is carried out in a batch,

statements about the response are certified in a certification generation phase.

A three-way handshake, basically,

and

collectively acting as a TLS client. With negotiation in the form of secret sharing

Is shared with the session key. We emphasize this pair of stages (similar to the rest of DECO)

Completely transparent so that no server side modifications are required.

For the CBC-HMAC cryptographic suite, at the end of the three-way handshake,

and

receive separately

And

at the same time

Receiving

As with the standard handshake, the user may choose to,

and

both obtain an encryption key k ^Enc 。

The three-way handshake may make the aforementioned session data submission unforgeable as follows. At the end of the session it is time to complete the session,

is first submitted to

As previously described, followed by

Reveal her share

From

From the perspective of (1), the three-way handshake protocol ensures that a new MAC key (for each direction) is used for each session, regardless of the impact of a potentially malicious prover, and the key pair

Is unknown until she commits. Without knowledge of the MAC key,

there is no way to forge or tamper with the session data before it is submitted to it. The non-forgeability of the session data submission in DECO thus reduces the non-forgeability of the MAC scheme used in TLS.

Other sets of cryptographic programs, such as GCM, may be similarly supported. In GCM, a single key (for each direction) is used for both encryption and MAC. The handshake protocol is similarly at

And with

A secret shared key is used between them. The handshake protocol for GCM is described in more detail elsewhere herein.

Since the session key is shared secretly, as mentioned, so

And

the interactive protocol is executed to construct a TLS message that encrypts the query.

Then sends the message to the client as a standard TLS

For CBC-HMAC, it computes the MAC tag of the query, while for GCM, it performs authentication encryption. Note that query pairs

Is private and should not leak to

Generic 2 PCs will be expensive for larger queries, so we instead introduce a custom 2PC protocol that is more efficient in magnitude level than generic solutions, as described elsewhere herein.

As has been explained previously, it is possible to,

upon receiving

Prior to submission to session data

Making the submission unforgeable. Followed by

The integrity of the response may be verified and statements about it may be certified as will now be described.

Proof of production Using an unforgeable submission if

Fully open commit

(i.e., revealing an encryption key), then

Can be easily verified by checking the decrypted MAC

The authenticity of.

However, the disclosure is for

Will break privacy: which will be disclosed in

And

all session data exchanged between. In theory, it is possible to use,

may instead prove with zero knowledge (i.e., without revealing the encryption key)

Any statement above, Stmt. However, the universal zero knowledge proof technique would be prohibitively expensive for many of the inherent options for Stmt.

Change of DECO intoTwo techniques were introduced that support efficient proof of statements for a broad general class, namely the "selective open" technique referred to herein as TLS session transcription. Selective opening involves opening to

Revealing substrings or revising (i.e., cutting out) substrings, thereby modifying (i.e., cutting out) substrings

Hiding the substring.

FIG. 5 shows a simplified JSON bank statement of a user Bob acting as a prover as an illustrative example. This example will be used to expose selective opening and context integrity attacks. Suppose Bob

Want to move to

Revealing his checking account balance. Revealing the decryption key for his TLS session would be undesirable: it will also reveal the entire statement, including his transaction. Alternatively, using the techniques disclosed herein, Bob may efficiently disclose only the substrings in lines 5-7. Alternatively, if he does not intend to reveal his savings account balance, he may revise his transaction after line 7.

Two selective open modes (revealing and revising substrings) are useful privacy protection mechanisms. It may also serve as a pre-process for subsequent zero knowledge proofs. For example, Bob may want to prove that he has an account with a balance greater than $1000 without revealing the actual balance. He will then prove with zero knowledge an assertion on the substring containing his checking account balance ("balance > $ 1000").

However, selective opening alone is not sufficient for many applications. This is because the context of the substring affects its meaning. Without what we call context integrity,

can cheat and reveal that a mistake is expressed as

A declared substring is certified. For example, Bob may not have a balance above $ 1000. However, after viewing his bank statement, he can publish to the customer service in the same TLS session with substring "balance": $5000 messages, and then look at his pending messages (in the form of a reflection attack). He can then reveal this substring to spoof

Supply to prover

Various sanitization heuristics of input (e.g., truncating session transcription) may potentially prevent some such attacks, but as with other forms of web application input sanitization, it is vulnerable and vulnerable to attack.

Instead, we introduce rigorous techniques by which session data is explicitly but secretly parsed. We refer to this technique as "zero knowledge two-stage parsing". According to the technique of the present invention, it is possible to,

resolving locally in a first phase

And then with zero knowledge to

A statement is proved regarding the constraints on the resulting substring. For example, in our banking example, if the bank-supplied key value store is always escaped with the diacritic λ, then Bob may escape by parsing locally and forwarding to

Revealing the substring "balance" preceded by λ: $5000 to prove the correct balance. It can be shown that for the very common class of network API syntax (unique key), this two-stage approach produces far more efficient proofs than the more general-purpose techniques.

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

Three-way handshake

In some embodiments, the three-way handshake (3P-HS) is targeted to couple

In a completely transparent manner at the prover

And verifier

Between the server

The session key used in the TLS session. We first focus on describing CBC-HMAC, then adapt the protocol to support GCM.

FIG. 7 shows a formal specification of a three-way handshake protocol in an illustrative embodiment.

Fig. 8 shows an example ECtF protocol as part of a three-way handshake protocol in some embodiments.

Again, the specific details of these protocols are merely examples and are not limiting in any way. For example, in other embodiments, a wide variety of other types of three-way handshake protocols involving provers, verifiers, and servers may be used. Thus, the term "three-way handshake protocol" as used herein is intended to be broadly understood.

Like the standard TLS handshake, the 3P-HS comprises two steps: in the first place, the first,

and

computing a secret shared with a server via a TLS-compliant key exchange protocol

Is shared. ECDHE is recommended and focused here, but other techniques can be used for computing sharing; in the second place, the first place is,

and

the secret shared session key is derived by securely evaluating TLS-PRF with its share of Z as input, where PRF refers to a pseudo-random function. In the following we present a text description and therefore do not require formal specifications for understanding.

Step 1: key exchange hypothesis

Refers to the EC group used in ECDHE and G refers to its generator.

Proving device

By issuing a regular TLS handshake request with a random nonce r _c Is sent to

The handshake is initiated (in the ClientHello message). At the slave

Receiving the certificate, server nonce r _s And signed ephemeral DH public key

(in the Server Hello and ServerKeyExchange messages),

checks and forwards certificates and signatures to

After the same check has been made as for,

for secret s _V Sampling and applying DH public key Y _V ＝s _V G sends her part to

Which then deals with another secret s _P Sample and combine DH public key Y _P ＝s _P ·G+Y _V Is sent to

Due to the server

Run standard TLS, therefore

(and

) Calculate its share of Z as Z _P ＝s _P ·Y _S (and Z _V ＝s _V ·Y _S ) When the temperature of the water is higher than the set temperature,

the DH secret will be calculated. It should be noted that Z ═ Z _P +Z _V Wherein + is

The group operation of (1). Given that the discrete logarithm problem in the selected group is difficult, then Z is unknown to either party.

And 2, step: key derivation now

And

an additive share of Z (in the form of EC points) has been established, which derives the session key by evaluating the TLS-PRF keyed in the x-coordinate of Z.

The technical challenge here is to coordinate arithmetic operations in 2PC (i.e.,

add in) and bitwise operation (i.e., TLS-PRF). It is well known that boolean circuits are not well suited for arithmetic in large domains. As a specific estimate, EC-point addition, which only produces x-coordinates, involves 4 subtractions, one modulo inversion and 2 modulo multiplications. The estimation of AND complexity based on a very optimized circuit yields over 900,000 AND gates for subtraction, multiplication AND modular reduction only-even without inversion, which would require running an extended Euclidean algorithm inside the circuit.

Due to the prohibitive cost of adding EC points in boolean circuits,

and

using the ECtF protocol shown in fig. 8 will be

Into which the additive sharing of the EC-points in

X coordinate of (2). Then the Boolean circuit is only involved in

With two added numbers, this can be done with only-3 | p | AND gates, which are-768 AND gates in our implementation, where p is 256 bits.

ECtF protocol will be used to convert to a shared format using ECtF

Sharing conversion in (1)

Is shared. The inputs to the ECtF protocol are two EC points

Is marked as P _i ＝(x _i y _i ). Suppose (x) _s ,y _s )＝P ₁ ★P ₂ Wherein ≧ EC group operation, then the output of the protocol is

So that α + β ═ x _s . In particular, for the curve we consider, x _s -λ ² -x ₁ -x ₂ Wherein λ ═ y ₂ -y ₁ )/(x ₂ -x ₁ ). Y can be calculated similarly _s But we omit the computation, since TLS uses only x _s 。

ECtF uses multiply-pair-add (MtA) shared translation protocols as building blocks. We use α, β: operation of MtA between Alice and Bob with inputs α and b, respectively, is denoted MtA (α, b). At the end of the run, Alice and Bob receive α and β, so that a · b ═ α + β. The protocol may be generalized to handle vector inputs without increasing communication complexity. I.e. for vectors

If α, β: MtA (α, b), then (α, b) α + β.

We now describe the protocol of ECtF. ECtF has two main components. Let [ alpha ] be]2 of 2 shares referring to α, i.e., [ α]＝(α ₁ ，α ₂ ) So that i has an α for i e {1, 2} _i While α is ═ α ₁ +α ₂ . The first component is a sharing inversion: given [ alpha ]]Calculating [ alpha ] ^-1 ]. This can be done as follows: i-square to random value r _i Sample and execute MtA to calculate δ ₁ ，δ ₂ ：＝MtA((α ₁ ，r ₁ )，(r ₂ ，α ₂ )). Note that δ ₁ +δ ₂ ＝α ₁ ·r ₂ +α ₂ ·r ₁ . V published by Party i _i ＝δ _i +α _i ·r ₁ And thus both parties learn v ═ v ₁ +v ₂ . Finally, the i-side outputs beta _i ＝r _i ·v ^-1 . Protocol calculation of alpha ^-1 Because of beta ₁ +β ₂ ＝α ^-1 . Furthermore, the protocol does not leak α to any party that assumes MtA to be secure. In fact, the view of the i-side is represented by (α) ₁ +α ₂ )(r ₁ +r ₁ ) Composition due to r _i Are uniformly random and are uniformly random.

The second component is shared multiplication: calculating [ alpha b [ ]]Given [ alpha ]]，[b].[αb]The following can be calculated using MtA: the parties perform MtA to calculate alpha ₁ ，α ₂ So that α is ₁ +α ₂ ＝α ₁ ·b ₂ +α ₂ ·b ₂ . Then, the i-side output mi is equal to alpha _i +α _i ·y _i . The security and correctness of the protocol may be similarly demonstrated as above.

Having calculated the share of the x coordinate of Z in ECtF (so-called pre-master secret in TLS),

and

the TLS-PRF in 2PC is evaluated to derive the session key. Using the known SHA-256 circuit, we manually optimized the TLS handshake circuit, resulting in a circuit with a total AND complexity of 779,213.

Adapted to support GCM for GCM a single key (for each direction) is used for both encryption and MAC. Adapting the above protocol to support GCM in TLS1.2 is simple. The first step will remain the same while the output of the second step needs to be truncated because the GCM key is shorter.

TLS 1.3. to support TLS 1.3, 3P-HS protocol must be adapted to the new handshake flow and different key derivation circuits. It is worth noting that all handshake messages after ServerHello are now encrypted. An immature policy would be to decrypt the message in 2PC, which would be expensive because the certificate is usually large. However, due to the key independence nature of TLS 1.3, we can construct a 3P-HS protocol similar to the complexity of TLS1.2, as described elsewhere herein.

Query execution

After handshaking, the prover

Inquire her

Sent to a server as a standard TLS client

But by means of a self-verifier

To help of (3). In particular, since the session key is shared secretly, both parties need to interact and execute the 2PC protocol to construct TLS record encryption

While a generic 2PC would theoretically be sufficient, it would be expensive for larger queries. We change toA custom 2PC protocol of a more efficient magnitude level is introduced.

We first focus on a round session, where

Sending all queries to before receiving any response

Most applications of DECO (e.g., provenance of content retrieved via HTTP GET) are round-robin. The DECO is extended to support multiple-loop sessions as described elsewhere herein.

CBC-HMAC

And

maintaining sharing of MAC keys while

The encryption key is saved. To construct TLS record encryption

(potential pair)

Private), both parties first run the 2PC protocol to compute

HMAC tag τ, and then

Encrypting locally

And send the ciphertext to

Let H refer to SHA-256. Remember that HMAC for message m with key k is

The terms ipad and opad refer to the respective "inside" and "outside" values utilized in the HMAC algorithm. A direct 2PC implementation would be expensive for larger queries because it would require hashing the entire query in 2PC to compute the internal hash. This is achieved by

The computation of the internal hash is done locally (i.e., without 2PC) and is advantageously avoided in the illustrative embodiment. If it is not

Is aware of

She can compute an internal hash. However, we cannot simply get it out of the way

Is fed to

As she can then learn k and forge the MAC.

Our optimization utilized Merkle Damgard (Merkle-

) And (5) structure. Suppose m ₁ And m ₂ Two correctly sized blocks. Then H (m) ₁ ‖m ₂ ) Is calculated as f _H (f _H (IV,m ₁ ),m ₂ ) Wherein f is _H Refers to the one-way compression function of H, and IV refers to the initial vector.

Fig. 9 shows a post-handshake protocol for CBC-HMAC.

After the three-way handshake, the user may,

and

performing simple 2PC protocol to compute

And to direct it to

Disclosed is a method for producing a semiconductor device. In order to compute the internal hash of the message m,

using only s ₀ The hash of m is computed as IV. Disclosure of s ₀ Does not disclose k ^MAC Because suppose f _H Is unidirectional. To compute HMAC (k, m) then involves computing the outer hash in 2PC over the inner hash, which is a much shorter message. Therefore, we can reduce the amount of 2PC computation to a few blocks regardless of query length, compared to up to 256SHA-2 blocks in each record with a generic 2 PC.

AES-GCM for GCM,

and

to proceed with

The authentication of (2) is encrypted. 2PC-AES is simple with optimized circuitry, but computing the label for larger queries is expensive because it involves evaluating a long polynomial in the large domain for each record. Our optimized protocol performs polynomial evaluations locally via pre-calculations, as described in more detail elsewhere herein. Since 2PC-GCM involves not only tag creation but also AES encryption, its odds ratio CBC-HMAC higher computational cost and latency.

Other embodiments disclosed herein utilize an efficient alternative protocol (referred to as a proxy mode protocol) that avoids the post-handshake 2PC protocol altogether under additional trust assumptions.

As illustrated in the full DECO protocol shown in fig. 6, after querying the server and receiving the response,

by sending the ciphertext to

But is submitted to the session and received

Is shared. Followed by

The integrity of the response may be verified and statements about it may be certified. FIG. 6 specifies the complete DECO protocol for CBC-HMAC. The DECO protocol for GCM is similar and is described elsewhere herein.

For clarity, we extract the ideal functionality

Details of zero knowledge proof of (1). At the slave

Upon receipt ("attestation", x, w), where x and w are private and public witnesses, respectively,

sending w and the relation pi (x, w) e [0,1} (defined below) to

In particular, for CBC-HMAC, x, w, π are defined as follows:

and

the relationship π (x, w) if and only if (1)

(and

) Is composed of

(and R) at key k ^Enc ,k ^MAC The CBC-HMAC ciphertext; (2)

and (3) stmt (r) ═ b, 1 is output. Otherwise it outputs 0.

Assuming functionality for secure 2PC and ZKP, it may show Prot as illustrated in FIG. 6 _DECO Implementing FIG. 3 securely for malicious adversary UC

More particularly, assuming that the discrete recording problem is difficult in the group used in the three-way handshake, and f (the compression function of SHA-256) is a random oracle, Prot _DECO Securely implementing UC against static malicious adversaries with aborts

In a mixed world

The protocol for GCM has a similar flow. The GCM variant of the three-way handshake and query construction protocol is described above.

Figure 10 shows the 2PC protocol for validating tags and decrypting records in the GCM variant. These are also referred to as post-handshake protocols for GCM.

Unlike CBC-HMAC, GCM does not commit: for a given ciphertext encrypted with Key k

A person knowing k can efficiently find what to do when passing an integrity check

K' ≠ k, which decrypts to a different plaintext. To prevent this attack, we need to

In the study of

Before submitting to her key share

In the certification generation phase, the certification is related to

And in addition to the statements of R,

there is also a need to prove for decryption

And

session key pair

Is valid. The proof of security of the GCM variant is similar to that of CBC-HMAC.

Proof generation

Memory prover

Submission to TLS sessionsIs encrypted by the encryption key

And to

The plaintext M is proven to satisfy certain properties. Without loss of generality, we assume

And M contains only one TLS record and is hereinafter referred to as a ciphertext record and a plaintext record. Multiple recording sessions can be handled by repeating the protocol for each recording.

Only provenance of M proves simple: only the encryption key is disclosed. But this sacrifices privacy. Instead of this, the user can,

any statement regarding M may be evidenced using general zero knowledge techniques. But such certification is often expensive.

In the following description, we present statements of two categories optimized for an example application: revealing only responsive substrings while proving provenance ("selective opening"), or further proving that revealed substrings appear in the text of the text

In the expected context ("context integrity by two-phase resolution").

Illustrative embodiments implement a technique referred to herein as a "selective open" technique, which allows for

The substrings in the plaintext are efficiently revealed or revised. Suppose a plaintext record consists of information block M ═ B ₁ ,…,B _n ) Composition (details of the blocks are discussed below). Selective open allowing

Ith letter proving MInformation block is B _i While not revealing the remainder of M; we call this a revealing mode. It can also prove M _-i Same as M but with the information blocks removed. We call this a revision mode. Both modes are simple but can be used for feasible privacy objectives. The granularity of selective opening depends on the cryptographic suite of programs, which we now discuss.

CBC-hmac. remember for proof generation,

saving encryption and MAC keys k ^Enc And k ^MAC Both of which are

Having only MAC key k ^MAC . Our performance analysis assumes a cryptographic suite of programs with SHA-256 and AES-128 that matches our implementation, but the technique is applicable to other parameters. Remember to use MAC followed by encryption: the plaintext record M contains up to 1024 AES data blocks and 3 MAC tag blocks σ, which we refer to as M ═ B (B) ₁ ,…B ₁₀₂₄ σ), where σ ═ B (B) ₁₀₂₅ ,B ₁₀₂₆ ,B ₁₀₂₇ ).

CBC encryption for M, consisting of the same number of blocks:

wherein

Revealing TLS records, certificates

In not disclosing k ^Enc The immature way of encrypting M in case of (a) is to prove the correct encryption of each AES block in ZKP. However, this would require up to 1027 AES calls in ZKP, resulting in unfeasible performance.

Using MAC connectionsWith the encryption structure, the same operation can be done using only 3AES calls in ZKP. This illustratively involves proving

The last few blocks of (a) encrypt the tag sigma and reveal the plaintext directly. In particular to the way in which the flow of air is controlled,

computing

And send (M, π) to

Then, the

Verify pi and check the MAC tag on M (note,

knows the MAC key). Its security depends on the collision resistance of the underlying hash function in the HMAC, i.e.,

m' ≠ M cannot be found with the same label σ.

A record with a revised chunk is revealed, assuming that the ith chunk contains

Sensitive information that is desired to be revised. The direct strategy is to prove B by calculation _i- ＝(B ₁ ,…,B _i-1 ) And B _i+ ＝(B _i1+ ,…,B _n ) Is formed by

Prefixes and suffixes of encrypted plaintext

But this is expensive as it would involve 3AES and 256SHA-256 compression in ZKP.

With the Merkel-Damgard structure of SHA-256, several optimizations are possible. Suppose f refers to the compression function of SHA-256, and s _i-1 Is referred to in B _i- The state after f is applied. First, if applicable, e.g., at B _i Revealing s when containing high entropy data such as API keys _i-1 And s _i Both, then only 1SHA-256 in ZKP can be used to achieve the above goal. In order to do so, it is proposed that,

calculating pi-ZK-PoK { B ═ _i ：f(s _i-1 ,B _i )＝s _i And will be (pi. s) _i-1 ,s _i ,B _i- ,B _i+ ) Is sent to

Which then 1) by passing from B _i- Recalculate it to check s _i-1 (ii) a 2) Verifying pi; and 3) by a slave s _i And B _i+ It is recalculated to check the MAC tag sigma. Suppose B _i For high entropy, then since f is unidirectional, s is revealed _i-1 And s _i Without leakage of B _i 。

On the other hand, if s _i-1 And s _i Both cannot be moved to

Disclose (e.g., as for B) _i When a brute force attack is feasible), then we can still make the pass

Revisions containing block B _i To reduce costs. The cost incurred next is the 256-iSHA-2 hash in ZKP. Additional details are provided elsewhere herein. In general, ZKP costs and record sizes areProportional, TLS slicing operations may also reduce costs by a constant factor.

Revision suffix when revision suffix B is to be revised _i+ When the temperature of the water is higher than the set temperature,

calculating out

And s _i Is at B _i- ‖B _i The state after f is applied.

Will (pi, B) _i- ‖B _i 0 is sent to

The validator then 1) passes at B _i- ‖B _i Check s by applying f _i-1 And 2) verifying pi. Basically, it safely follows the pre-imaging resistance of f. In addition, since ih ═ f (s, B) _i+ ) To

Keep secret, so

The revised suffix is not learned. The total cost is 3AES and 256-iSHA-2 hashes in ZKP.

The prefix is revised.

Calculating two ZKPs 1)

Will (pi) ₁ ,π ₂ ,s _i-1 ,B _i ‖B _i+ ) Is sent to

Verifier 1) uses pi ₁ Inspection of _i-1 Is correct and f(s) is then calculated _i-1 ,B _i ‖B _i+ ) To obtain an internal hash ih, 2) verify pi using the calculated ih ₂ . The cost incurred is 3AES in ZKP and 256-i SHA-2 hashing.

It should be noted that the revision prefix/suffix is only meaningful if the disclosed portion does not contain any private user data. If not, then,

it would be necessary to find the smallest substring containing all sensitive blocks and revise the prefix/suffix, similar to above.

GCM, unlike CBC-HMAC, blocks are revealed to be very efficient in GCM. First of all, the first step is to,

revealing AES (k, IV) and AES (k,0) with proof of correctness in ZK to allow

And verifying the integrity of the ciphertext. Then, in order to reveal the ith block,

revealing only the ith counter C with proof of correctness _i ＝AES(k,inc ⁱ (IV)) encryption.

Ith blocks can be decrypted because

Is a public initial vector for a session, and inc ⁱ (IV) refers to incrementing IV i times (the exact format of inc is not important). Is composed ofIt is disclosed that the TLS record,

the above protocol is repeated for each block. Also, additional details are provided elsewhere herein.

To summarize the above, CBC-HMAC allows efficient selective disclosure at the TLS record level and revision at the block level in the DECO, while GCM allows efficient disclosure at the block level. The selective opening may also serve as a pre-process to reduce the input length for subsequent zero knowledge proofs.

For many applications, a verifier

It may be desirable to verify that the disclosed substring occurs in the correct context. We refer to this property as "context integrity". In the following, we present methods for

Techniques to specify context and techniques for

Techniques to efficiently prove context integrity.

For ease of explanation, our following description initially focuses on the revealing mode, i.e.,

expose server pair

The substring of the response of (1). The revision mode will be described next.

Our technical assumptions for specifying context are sent to a given server

And TLS protected data sent from the server has a pair

And

both known and well-defined context-free grammars

In case of slight abuse of symbols, we assume that

Refers to both the grammar and the language in which it is specified. Therefore, the temperature of the molten metal is controlled,

is referred to by

A string R in a given language. Let us assume that

To be specific, i.e. each

Having a uniquely associated parse tree T _R . JSON and HTML are examples of two widely used languages that meet these requirements and are the focus of us here.

When in use

Then present from

Some of the substrings R of response R _{Open by opening} When we say that we are passing

Expected generation of R in some way _{Open by opening} In the case of (1), R _{Open and open} With context integrityAnd (4) sex. In particular to the way in which the flow of air is controlled,

specify a set of locations S in which she can expect to see valid substrings R in R _{Open and open} . In our definition, S is from

A set of paths from the root to the internal nodes in the defined parse tree. So S e S, we refer to the non-end sequence of the admissible path. Suppose ρ _R To denote T _R Root of (2) ((

The parse tree for R in (1). We say if T _R Having subtrees whose leaves produce (i.e. are concatenated to form) a string R _{Open and open} ) Then character string R _{Open and open} With contextual completeness with respect to (R, S), and presence from ρ _R The path S to the root of the tree is S.

Formally, we are based on assertions

The context integrity is defined. More particularly, at the time of TLS response

Grammar of (2)

Substring R of R _{Open and open} In the case of a set of allowable paths S, we apply the context function

Defined as a Boolean-type function such that if and only if there is a slave

To

S ∈ T of S _R Of subtrees

And is

Generation of R _{Open and open} When the temperature of the water is higher than the set temperature,

R _{open and open} Is said to be in

In the true case there is context integrity with respect to (R, S).

Referring again to the example of fig. 5, consider a JSON string J in accordance with the example. JSON contains the following rules (roughly):

start → object → { Pair }

Pair → "key" → value pair → pair | pair, pair

Key → char value → char | object

In the case of the above-described example,

pairing p of pair learning by checking a/c with a key _{Inspection of} Is given as a "balance" pairing with a key in the object ρ _{Balance of} Is of interest. Each of these non-endings is used to parse the tree T _J The node in (1). From T _J From the root to p _{Inspection of} The path of (c) requires traversal of the form start → object → pair → p _{Examination of} Wherein a pair denotes a sequence of zero or more pairs. S is a group of such sequences and R _{Open and open} For the string "check a/c": { "balance": $2000 }.

In general, R is demonstrated without direct disclosure of R _{Open and open} With the integrity of the context, i.e.,

this is due to the calculation

It may be desirable to calculate T for potentially longer strings R _R . However, we have observed that under certain assumptions that TLS-protected data generally satisfies, this can be achieved by making the TLS-protected data

By applying

And

transforming Trans of agreement and preprocessing R removes much overhead and certifies R _{Open and open} Relative to R '(usually a much shorter string) and S' (composed of

A set of allowable paths specified based on S and Trans) has contextual integrity.

Based on this observation, we introduce techniques for efficient computation of R _{Open and open} And certify

Suppose that

And

protocol

Syntax used by the web server, and transform Trans. Suppose that

To be used for all

The syntax of (2) string Trans (R). Based on the Trans, the method of the present invention,

specifying allowable Path S' and constraining Condition checking function

In the first phase of the process,

(1) computing a substring R of R by parsing R _{Open by opening} (so that

) (2) calculating another character string R' ═ trans (R). In the second stage of the process, the first stage,

with zero knowledge to

Identification (1)

And (2)

It should be noted that in addition to disclosing parameters

S、S′、Trans、

In addition, the validator only sees submissions to RAnd finally, R _{Open and open} 。

This protocol makes zero knowledge calculations significantly cheaper by deferring actual resolution to unverifiable calculations. In other words,

and

are comparable in calculation

Is much more efficient to compute.

We formalize the correctness conditions for two-stage parsing in the operational semantic rules given below. Here, the first and second liquid crystal display panels are,<f,σ>refers to applying the function f on the input σ, and

refer to if precondition P is true, then conclusion C is true.

In a given grammar

Context function and allowable paths

Transform Trans, with context function and tolerable path

Sum function

Grammar of

In the case of (A), we say that if R is satisfied for all of (R, R', R) _{Open and open} ) So that

B, n of Boolean typeExercise apparatus

With respect to S being correct, the following rule holds:

below, we focus on an example syntax suitable for use in a DECO application, and present a specific construction of a two-stage parsing scheme.

A wide class of data formats, such as JSON, have the concept of key value pairs. Thus, it is our focus in some embodiments of DECO.

Key value syntax

According to the rule "Pair →Start ofSecret keyIntermediate ofValue ofEnd up"generating a key value pair, whereinStart of、Intermediate (II)Andend ofIs a delimiter. For such grammars, the optimized array can greatly reduce the complexity of the attestation context. We discuss several such optimizations below, with additional details provided elsewhere herein.

For key value syntax

Path set S if for

Substring R conforming to context integrity _{Open and open} R needs to be keyed with a global unique key K _{Open and open} Resolve to a key value pair, then R _{Open and open} Only the substring of R is needed and correctly resolved as a pair. In particular, Trans (R) outputs a substring R' of R containing the required key, i.e., the form "Start ofKIntermediate (II)Value ofEnd up"and

can output R _{Open and open} ＝R′。

Can be regulated by

Wherein

Is used for

Generates the start symbol in the rule. Then (1)

Check the substring that R' is R and (2) for

Inspection (a)

And (b) R _{Open and open} R'. In some applications herein, a globally unique key is generated, for example when selectively opening a response to age.

So far, our description of two-phase parsing assumes that patterns are revealed, where

To the direction of

Revealing the substring R of R _{Open by opening} And proving R _{Open and open} Relative to the device composed of

The specified set of allowable paths has contextual integrity. In the revision mode, the process is similar, but

Generation of pairs R using the previously described techniques _{Open and open} Is removing R _{Open by opening} For example, by replacing its location with a dummy character, rather than explicitly revealing R _{Open by opening} 。

Applications of

The DECO disclosed herein can be used in any predictive machine based application. To illustrate its versatility, we have implemented and evaluated three example applications that take advantage of their various capabilities: 1) a confidential financial instrument implemented by a smart contract; 2) converting the legacy credential into an anonymous credential; and 3) privacy preserving price discrimination reporting.

Financial derivatives are among the most commonly listed intelligent contract applications, and illustrate the need to authenticate data feeds (e.g., stock prices). For example, one popular financial instrument that is easily implemented in smart contracts is a binary option. This is the price P between the two parties for some assets N at a specified future time (e.g., the end of day D) ^* Whether or not the predetermined target price P (i.e., P) will be equal to or exceeded ^* P) or more. Intelligent contract calling prophetic machine for implementing this two-value option

To determine the result.

In principle, for a binary option in a chain,

the base asset N and the target price P may be hidden. It accepts only option details under the chain and reports only the specified result Stmt: ═ P ^* ≧? The bit of P. This process is called Mixicle.

The limitation of the basic Mixicle construction is that,

learn details of the financial instrument itself. Prior to DECO, a prolog service using only Trusted Execution Environment (TEE) may be provided to

The query is hidden. We now show how DECO can be found in

Binary option execution is supported without learning the details of the financial instrument (i.e., N or P). In this regard it should be noted that ≧ are the assertion direction ≧? Or ≦? May be randomized. In addition, winner and loser identities and payment amounts may be hidden. Additional steps may be taken to hide other metadata, such as accurate settlement time.

In this example application, the option winner comes into play

And exert the functions of

Of (2) act

Signed result Stmt is obtained. We now describe the protocol and its embodiments.

Suppose that

A key pair referring to a predictive engine. In this embodiment, the binary option is specified by an asset name N, a threshold price P, and a settlement date D. We pass through the witness r _M C of (A) _M ＝com(M,r _M ) Refers to the submission of message M.

Fig. 11 illustrates both Alice and Bob executing a confidential binary option. Alice uses DECO to access the stock price API and make

Confident that she has won. Examples of requests and responses are shown to the right, and shaded text in this portion of the figure is sensitive information to be revised.

The binary option process illustrated in fig. 11 includes the following steps:

1) setting: alice and Bob agree on a binary option { N, P, D } and create a binary option with an identifier ID _SC Intelligent contracts SC. The contract contains

Addresses of parties and options for parties with witnesses known to both parties { C _N ,C _P ,C _D And (5) submitting the file. It also agrees with the public parameter theta _P (e.g., a URL to retrieve the price of the asset).

2) And (4) settlement: suppose Alice wins the transaction. To ask for pay, she uses DECO to generate a ZKP that matches her location for the current asset price retrieved. Alice and

performing a DECO protocol (wherein

Acting as a verifier) to obtain a signal from theta _P (target URL) retrieve asset prices. We assume that the response contains (N) ^* ,P ^* ,D ^* ). Divide ZKP in DECO to prove origin θ _P In addition, Alice also demonstrates the following statement:

ZK-PoK{P,N ^* ,P ^* ,D ^* ,r _N ,r _P r _D ：(P≤ ^* )∧

C _N ＝com(N ^* ,r _N )∧C _P ＝com(P,r _P )∧C _D ＝com(D ^* ,r _D )}。

upon successful proof verification, the propheter returns a signed statement ID with the contract,

3) paying: alice provides a signed statement S to the contract that verifies the signature and pays the winner.

Alice and Bob need trust

Integrity (but not privacy). As explained elsewhere herein, it may further be hedged against integrity failures by using multiple predictors. Decentralizing trust on a predictive machine is a standard and deployed technology. We emphasize that DECO ensures privacy even if all the predictive machines are malicious.

As indicated above, FIG. 11 shows the request and response of the stock price API. User' s

It also requires a speech predictor

Sufficient portions of the HTTP GET request are revealed to ensure access to the correct API endpoint. The GET request contains several parameters, some of which are revealed similar to API endpoints, and others of which have sensitive details similar to stock names and private API keys.

Revising and converting sensitive param using the techniques disclosed herein

The remainder is disclosed. API key provisioning prevention

Sufficient entropy for learning sensitive param. But without additional attention, cheating

The semantics of the GET request can be altered and the cheating hidden by revising additional parameters. In order to ensure that this does not occur,

need to prove delimiter'&"and separator" — "do not appear in the revised text.

Suppose that

And R refers to response ciphertext and plaintext, respectively. In order to settle the option(s),

using the previously described two-phase resolution scheme

Proving that R contains evidence that he won the option. In the first phase of the process,

resolving R locally and identifying can enable

The smallest substring of R that is believed. In the embodiment of FIG. 11, which relates to stock prices, R _Price The product is qualified by '05. price' and '1157.7500'. In the second stage of the process, the first stage,

demonstrated by ZK (R) _Price ,P,r _P ) Such that 1) R _Price Is composed of

The decrypted substring of (a); 2) r _Price Beginning at "05. price"; 3) the subsequent character forming a floating point number P ^* And said P is ^* More than or equal to P; and 4) com (P, r) _P )＝C _P 。

Assuming that the key is unique and the key "05.price" is followed by a price, this two-phase parsing is secure, so that the syntax of this response is the key value syntax with the unique key, as described above. In a similar manner to that described above,

the certification contained in R matches the submission with the name and date of the stock. In the case of the CBC-HMAC cryptographic suite, the zero knowledge proof circuit involves revising the entire record (408 bytes), computing commitments, and string processing.

HTTP GET requests (and HTML) have special restrictions: the boundary between the key and the value (i.e.,intermediate (II)) And the start of the key-value pair (i.e.,start of) Never a substring of keys or values. This means that in order to revise more than a single consecutive key or value,

must be revisedIntermediate (II),Start ofThe character in (c). So we make

And (4) checking: (1) r | ═ R' |; and (2)

Or R [ i ]]＝R′[i](D is a dummy character for in-situ revision). Then it is not necessary to check

Legacy to anonymous credentials: user credentials are typically inaccessible outside of the service provider's environment. Some providers provide third party API access via OAuth tokens, but such tokens reveal the user identifier. DECO allows users to save credentials in existing systems (we call "legacy credentials") to anonymously prove statements about them to third parties (verifiers). Thus, in some embodiments, DECO allows a user to convert any network-based legacy credentials into anonymous credentials without server-side support or trusted hardware.

Fig. 12 shows an example of this application, where a student uses a voucher (demographic details) stored on a college website to prove that her/his age is over 18 years. The student may provide this proof of age to any third party, such as the government issuing the driver's credentials or the hospital seeking permission for a medical examination. We implement this example using the AES-GCM cryptographic suite and two-stage parsing with unique key-based optimization.

In the example of fig. 12, the demographic details of the students stored on the university website include names, dates of birth, student IDs, and so forth. The highlighted text contains the student's age. The disclosed schema is used with two-stage parsing. The prover parses 6 to 7 AES blocks containing the date of birth and proves to the verifier that her age is above 18 years old with ZK. Similar to the other examples, this is also a key value syntax with a unique key due to the unique HTML tag that surrounds the birth date. Similar to the binary option application, this example requires additional string processing to parse the date and calculate the age.

Price discrimination means that the same product or service is sold to different buyers at different prices. Ubiquitous consumer tracking enables online shopping and booking sites to employ sophisticated price discrimination, e.g., adjusting prices based on customer zip codes. Price discrimination can result in economic efficiency and is therefore widely tolerated under existing laws.

However, in the united states, FTC prohibits price discrimination if it causes competitive harm, and new privacy-focused laws in europe (e.g., GDPR) refocus on the legitimacy of this practice. Consumers are generally reluctant to undergo price discrimination in any event. Currently, however, there is no trusted way for users to report on-line price discrimination.

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

As illustrated in fig. 13, the portion of the order invoice page in HTML on a shopping website (e.g., Amazon) contains personal details, such as the name and address of the buyer. The buyer wants to convince a third party (verifier) of the price charged for a particular product on a particular date. In this example, we use the AES-GCM cipher suite and reveal mode to reveal the necessary text in the upper portion of the order invoice page, while the shaded sensitive text in the lower portion (including shaded buyer name, address and city) is hidden. The number of AES blocks revealed from the response is 20 (due to the longer product name). In addition, 4AES blocks from the request are revealed to prove access to the correct endpoint. Contextual integrity is guaranteed by revealing surrounding unique strings, e.g., the string around the price of an item "< tr > Order Total:" appears only once in the entire response.

Implementation and evaluation

We now describe implementation details and evaluation results of DECO and three applications.

We implement the three-way handshake protocol (3P-HS) and the query execution protocol (2PC-HMAC and 2PC-GCM) for TLS1.2 in approximately 4700 lines of C + + code. We constructed a manually optimized TLS-PRF circuit with a total AND complexity of 779,213. We also use a variant of the known AES circuit. Our embodiment uses reic for the Paillier cryptosystem and EMP toolkit for the malicious security 2PC protocol.

We integrate three-way handshaking and the 2PC-HMAC protocol with the popular TLS implementation, mbedTLS, to build an end-to-end system. The 2PC-GCM can be similarly integrated into TLS with more engineering effort. We evaluated the performance of 2PC-GCM alone. The performance impact of the integration should be negligible. We do not implement the 3P-HS for TLS 1.3, but consider that the performance should be comparable to that for TLS1.2, since the circuit complexity is similar.

We evaluated the performance of DECO in both LAN and WAN settings. Both the prover and verifier run on the c5.2xlarge AWS node with an 8vCPU core and 16GB RAM. We located the two nodes in the same region (but different availability zones) in the LAN setting, but in two different data centers (in ohio and oregon) in the WAN setting. The round-trip time between two nodes in the LAN and WAN is about 1ms and 67ms, respectively, and the bandwidth is about 1 Gbps.

Table 1 below summarizes the run time of the DECO protocol during the TLS session. The mean and standard error of the mean (in brackets) were calculated using 50 samples. The MPC protocol we use relies on offline preprocessing to improve performance. Since the offline phase is input independent and target independent, it can be done before the TLS session. Only the online phase is on the critical path.

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

As shown in table 1, the DECO protocol is very efficient in LAN settings. It takes 0.37 seconds to complete the three-way handshake. For query execution, 2PC-HMAC is efficient (0.13 s per record) because it only involves one SHA-2 evaluation in 2PC, regardless of record size. 2PC-GCM is generally more expensive and the cost depends on the query length, since it involves 2PC-AES over the entire query. We evaluate its performance with queries in the 256B to 2KB range (see typical size in HTTP GET requests). In a LAN setting, the performance is efficient and comparable to 2 PC-HMAC.

In WAN settings, runtime is dominated by network latency, as MPC involves many rounds of communication. However, performance is still acceptable under the conditions that DECO may only see periodic use for most applications we consider.

We instantiated the zero knowledge proof with the standard proof system in libsnark. We have designed presentation templates that can be efficiently certified, but users of DECO need to adapt them to their specific application. The SNARK compiler enables this adaptation in high-level languages, hiding low-level details from developers. We use xjsnark and its Java class high level language to build statement templates and libsnark compatible circuits.

We chose the basic basis for libsnark as its relatively mature tooling support. The proof produced by libsnark is of constant size and the verification is very efficient, with the downside being a per-circuit trusted setting. With more effort, DECO may be adapted to use, for example, buckettproof, which does not require trusted settings, but has greater certification and verification times.

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

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 feasible prover performance. Since libsnark is optimized for low authentication overhead, the authenticator time is negligible. The number of constraints (and prover time) for the binary option application is highest due to the extra string parsing routine. We use multiple proofs in each application to reduce peak memory occupancy. For the most complex applications, the memory occupancy is 1.78 GB. Since the libsnark proves to be of constant size 287B, the demonstrated size is shown as a multiple thereof.

Table 2: the cost of ZKP is generated and validated in the proof generation stage of the DECO for the application.

DECO end-to-end performance depends on the available TLS cryptographic suite, the size of the private data, and the complexity of the application-specific proof. Here we present the end-to-end performance of the most complex of the three applications we implement (binary options). It takes about 13.77s to complete the protocol, which includes the time it takes to produce an unforgeable submission (0.50s), run the first stage of the two-stage parsing (0.30s), and produce a zero knowledge proof (12.97 s). Calculating these numbers in the LAN settings; in the WAN setting, the MPC protocol is more time consuming (5.37s), pushing the end-to-end time to 18.64 s.

In contrast, Town Crier performs similar applications using TEE within about 0.6s (i.e., about 20 x faster than DECO), but with added trust assumptions. Since DECO may only be used periodically for most applications, its overhead to achieve cryptographic strength security guarantees seems reasonable.

Problems of law and compliance

While the user may have retrieved their data from the website, DECO allows the user to output the data with the integrity certification without their explicit approval or even perception. We now briefly discuss the resulting legal and compliance considerations.

However, it is critical that the DECO user cannot export data with integrity guarantees to third parties in one direction, but relies on the prediction machine acting as a verifier for this purpose. When the DECO keeps the user data private, the predictive engine learns the websites and data types the user visits. Thus, the propheter may enforce appropriate data usage, e.g., deny transactions that may lead to copyright infringement.

Both the user and the predictive speaker have legal responsibility for the data that they access. However, recent case law on Computer Fraud and Abuse Act (CFAA) shows criminal transition from network capture, and federal law adjudication to violation of website's service terms is not itself a criminal act. Users and predictive machines that violate the terms of the web service (e.g., "click wrap") become at risk of civil penalties. It is a site and application specific issue that DECO complies with the terms of service for a given site.

The predictive engine has the incentive to establish itself as a trustworthy entity within intelligent contracts and other ecosystems. We expect that a well-credited predictive engine will provide the user with a menu of the specific confirmations they post and the target web sites they approve, review these options to maximize security and minimize liability, and possibly notify or collaborate with the target server.

Also of importance are legal, performance and compliance implications based on incorrect validation of incorrect (and possibly corrupted) data. However, today's internet services have complex multi-site data dependencies, and therefore these problems are not specific to DECO. The predictive engine service has relied on multiple data sources to help ensure correctness. The predictive-machine service can typically end up producing an infrastructure similar to that of a certificate, including online review and revocation capabilities and different levels of security.

DECO in the illustrative embodiments disclosed herein is a privacy-preserving, decentralized prescaler scheme for modern TLS versions that does not require trusted hardware or server-side modifications. DECO allows a prover to generate an unforgeable submission to a TLS session and efficiently prove statements about the contents of the session. Some embodiments leverage a novel two-phase resolution scheme to mitigate context integrity attacks that are common to privacy preserving speakers. The DECO can release data from the centralized network services repository, making it accessible to rich applications. The utility of DECO is demonstrated herein by a fully functional implementation along with three example applications.

Protocol details of GCM

GCM is an Authenticated Encryption (AEAD) cipher using extra data. For encryption, the GCM cipher takes as input the tuple (k, IV, M, a) secret key, initial vector, plaintext of a plurality of AES blocks and additional data to be included in the integrity protection; which outputs ciphertext C and tag T. Decryption reverses the process. The decryption cipher uses (k, IV, C, a, T) as input and first checks the integrity of the ciphertext by comparing the recalculated tag with T, then outputs the plaintext.

Compute ciphertext in counter mode:

wherein inc ⁱ Refer to incrementing IV i times (the exact format of inc is not important).

The label (k, IV, C, a) is calculated as follows. In a given vector

In the case of (1), the associated GHASH polynomial

Is used in

The addition and multiplication performed in (A) is limited to

Without damagingWithout loss of generality, assume that a and C are properly filled. Let l _A And l _C Refers to its length. GCM tag is

Where h is AES (k, 0).

When using GCM in TLS, each plaintext record D is encrypted as follows. The unique nonce n is selected and the 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 | GCM (k, n, D, κ).

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

Query execution

Computing or validating the GCM tag involves evaluating equation (1) above in 2 PC. The challenge is that equation (1) involves arithmetic calculations (e.g.,

polynomial evaluation in (e.g.) and binary computation (e.g., AES). Multiplication in large domains in binary circuits is expensive, while in large domains

Calculate AES (in GF (2) ⁸ ) Defined in (b) incurs high overhead. Even though the computation may be separated into two circuits in some way, only the polynomials are evaluated (this is recorded for each record in

Where approximately 1,000 multiplications are used) would also be prohibitively expensive.

Our protocol removes the need for polynomial evaluation. The actual 2PC protocol involves only binary operations and can therefore be done in a single circuit. Furthermore, the per record calculation is reduced to only one call of 2 PC-AES.

This is done by calculating { h (in 2PC protocol) { in the preprocessing phase at the beginning of the session ⁱ And (c) sharing of the same. The overhead of preprocessing is amortized over the session due to the same h for all records after (amortized). Using { h ⁱ The sharing of the stream is carried out,

and

the polynomial evaluation can be computed locally

To share. It also calculates AES (k, IV) in 2PC to get share of Tag (k, IV, C, A). In general, only one call of 2PC-AES is needed to check the label of each record.

It is important that,

never respond more than once to the same IV; otherwise

H will be learned. In particular, in each response,

disclose and present

Form of her share

Blind linear combination of (1). Importantly, the values are blinded by AES (k, IV) because

Is not blindThe linear combination will allow

And solving for h. Therefore, if

Respond twice to the same IV, then two responses may be added (at

Middle) to remove blinding:

this follows the temporary value uniqueness requirement of GCM.

Once the tag is properly checked, decryption of the record is simple.

And

the AES encryption of inc' (IV) with 2PC-AES is simply calculated. The subtlety to be noted is that,

it has to be checked that the counter to be encrypted has not previously been used as IV. If not, then,

h will be learned to in a manner similar to that outlined above

Proof generation

Blocks are disclosed.

Want to make

Make sure AES Block B _i For encrypting records

Ith block in (1). The proof strategy is as follows: 1) certifying AES Block B _i Encrypt to ciphertext block

And 2) certify the tag is correct. It turns out that only 1 AES in ZKP is needed for correct encryption. Without the creation of a radix rehmanniae, it was demonstrated that the correct label elicited 2AES block encryptions in the GHASH polynomial and ZKP of evaluation order 512.

We can pass through the permission

To

Two encrypted messages AES (k, IV) and AES (k,0) are disclosed to enable much more efficient attestation, allowing

The tag is verified (see equation (1)).

It is only necessary to prove that the correctness of the encryption in ZK and the key used corresponds to the commit, thus requiring 2AES and 1SHA-2(

Submitted to by revealing hashes of the keys

). Therefore, the total cost in ZKP is 3AES and 1 SHA-2.

The certification technique is a simple extension from the above.

Reveal the entire record rec and prove the correct AES encryption of all AES blocks, resulting inA total of 514AES and 1SHA-2 in ZKP.

TLS records are disclosed, except for blocks, similar to the above,

the encryption of all blocks in the record except one block is certified, resulting in a total of 513AES and 1SHA-2 in ZKP.

Protocol extension

Adapted to support TLS 1.3, the 3P-HS protocol must be adapted to the new handshake flow and the different key derivation circuits. It is worth noting that all handshake messages after ServerHello are now encrypted. An immature policy would be to decrypt the message in 2PC, which would be expensive because the certificate is usually large. Due to the key independence nature of TLS 1.3, however,

and

the handshake encryption key can be securely revealed without affecting the secrecy of the final session key. Handshake integrity is protected because the completed message authenticates the handshake using yet another independent key.

Thus, the optimized 3P-HS functions as follows.

And

ECDHE was performed as before. It then derives the handshake and application key by executing the 2PC-HKDF, and sends it to

Revealing handshake keys to allow

The handshake messages are decrypted locally (i.e., without 2 PC). 2PC circuit relates toRoughly 30 calls for SHA-256, totaling about 70k AND gates, is comparable to the call for TLS 1.2. Finally, since CBC-HMAC is not supported by TLS 1.3, DECO can only be used in GCM mode.

For applications that bind responses to queries, for example, when stock quotes are included with quotes, the 2PC query construction protocol may be avoided altogether. Since TLS uses separate keys for each direction of communication, it can be done after handshaking

Revealing client-to-server keys such that

Can be out of the way of

The server is queried in the case of an interaction.

DECO is extensible to support multi-turn sessions, where

Further queries are sent depending on the previous response. After each of the rounds, the result is obtained,

a similar 2PC protocol is performed as above to validate the MAC tag of the incoming response, since MAC validation and creation are symmetric. However, additional commit is required to prevent

MAC authentication is abused to forge the tag.

In TLS, different MAC keys are used for server-to-client and client-to-server communication. In order to support a multi-round session,

and

run 2PC to verify the label for the former and create a label on the new message for the latter. The previous description herein specifies the protocol used to create (and verify) the MAC tag. We now discuss additional security considerations for multi-turn sessions.

When checking the tag of a server-to-client message, we have to ensure that

It is not possible to forge a tag on a message that was not originally from the server. Suppose that

It is desired to verify the tag T on the message M. Let us make

First submitted to T, then

And

the 2PC protocol is run to calculate the tag T' on the message M. Require that

Open pair

And if T ≠ T', then

The protocol is aborted. Due to the fact that

Does not know the MAC key, so

Cannot be computed and submitted on messages not coming from the serverThe label of (1).

When creating a ticket for a client-to-server message,

it is ensured that the MAC tag is created on the message with an increased sequence number according to the requirements of TLS. This also prevents maliciousness

Two messages with the same sequence number are created because there is no provision for

Distinguishing which is sent to the server.

Alternative DECO protocols: as shown in table 1, the HMAC mode of DECO is efficient and the runtime creating and verifying HMAC tags in 2PC is independent of record size. The GCM mode is efficient for small requests with preprocessing, but can be expensive for large records. We now present an efficient alternative to avoid the post-handshake 2PC protocol altogether.

In this alternative, the verifier

Acting as a prover

And TLS server

The proxy between them, that is,

by passing

Sending a message to

Receive messages therefrom. Of the DECO protocolThe modified flow is as follows: after the three-way handshake, the user can,

submitted to her key sharing

Followed by

To the direction of

Disclosed is a method for producing a polycarbonate

Therefore, the temperature of the molten metal is controlled,

now with the whole session key

Due to the fact that

Continue the session with the server using k, so

And recording the proxy service. After the end of the session has been completed,

the statements about the recording session are certified as before.

In such embodiments, the three-way handshake provides non-forgeability. Unlike CBC-HMAC, GCM does not commit: given a ciphertext and a label encrypted with key k (C, T0, it can be found that decrypting C into k' ≠ k for different plaintexts when computing the same label, since the GCM MAC is not collision-resistant

Submitted to her key sharing before learning the session key.

The security properties and network assumptions associated with the proxy mode protocol will now be described. The verifier integrity and privacy nature is clear because of maliciousness

The integrity and privacy of TLS cannot be broken (by assumptions).

However, for prover integrity, we need to assume that the proxy can reliably connect to the whole session

First, we assume that the agent can determine that it is actually in conjunction with

And (4) connecting. Furthermore, we assume that there is a proxy and

cannot be informed of the session key and can therefore modify the content of the session

And (5) tampering.

It should be noted that, during a three-way handshake,

the identity of the server can be validated by checking the signature of the server on the new nonce (in standard TLS). After the hand is held, however,

it must rely on a network layer indicator, such as an IP address. In the practice of the method, the first and second,

it is therefore necessary to have the correct, up-to-date DNS record, and

the network with the server (e.g., its ISP and backbone network) must be properly assured against traffic injection, e.g., through Border Gateway Protocol (BGP) attacks. In the illustrative embodiment, there is generally no eavesdropping problem.

These assumptions have been covered by other systems in similar proxy settings, as BGP attacks are challenging to install in practice. We can further enhance our protocol to resist traffic interception by distributing the verifier nodes geographically. Further, various known detection techniques may be deployed by the verifier. BGP attacks are typically recorded after the fact, so, when applicable, the application of DECO can be enhanced to support revocation of affected sessions (e.g., when DECO is used to publish credentials in an identity system).

This alternative protocol represents a different performance-security tradeoff. It is efficient because intensive cryptography does not occur after the handshake, but it requires additional assumptions about the network and therefore only bears weaker network adversaries.

Key value syntax and two-stage parsing

We refer to context-free grammar (CFG) as

Wherein V is a set of non-end symbols, Σ is a set of end symbols, P: V → (V ∑ U) ^* Is a set of production or rules and S e V is a start symbol. We use '-' to refer to a set of subtractions and use '-' to refer to a range to define the production rules for a CFG with standard notation. For a string w, the parser determines whether to use w by constructing a parse tree for w

The parse tree representation can then be used to extract a sequence of production rules for semantics.

These are syntaxes with the concept of key value pairs. These syntaxes are particularly interesting for DECO, since most API calls and responses are in fact key value syntaxes.

If grammar exists

Then

By a syntax called key value, so that given any

In the case of (a) the (b),

and

can be defined by the following rules:

s → object

Object → Pair-free string open versus one or more pairs closed

Pair → start key middle value end

Pair → pair of one or more pairs | ")"

Key → char

Value → chars | object

chars→char chars|""

char → unicode-escape | added Chars

Special → Start Special | intermediate Special | end Special

Start of→ escape from the future _s Start special

Intermediate (II)→ escape from the future _m Intermediate special features

End of→ escape from the future _e Finish special

Escape → special | escape |.

In the above, S is a start non-end (meaning

Sentence in (b) open and close at non-end distinguishes between the opening and closing of the group by the key value, andstart of、Intermediate of、End upTo distinguish between the start of a key value pair, the separation between keys and values, and the special strings for which the pairing ends, respectively.

To remove ambiguity when parsing a special character (i.e., a character having a special meaning when parsing a grammar), special non-end escape is used. For example, in JSON, a key is parsed preceded by a 'space double quotation mark' (") and followed by a double quotation mark. If the key or value expression itself must contain a double quote, it must be preceded by a backslash (\), i.e., a escape. In the above rules, the non-end unambiguous preceding the special character means that it can be resolved into the special character. Thus, forward, we can assume that the generation of key-value pairs is unambiguous. Therefore, if key value syntax

The substring R 'of the string R in (b) resolves into a pair, then R' must correspond to a pair in the parse tree for R.

It should be noted that, in the above key value syntax,intermediate (II)No empty strings can be derived, i.e. non-empty strings must be markedIntermediate (II)To allow the key to be parsed from the value. However,start ofAndend upOne may have a null derivation since it only distinguishes the separation between the value in one pair and the key in the next pair. Finally, we should note that in some embodiments, in the two-stage parsing of the key value syntax, we only consider strings R with selective openness _{Open and open} Corresponding to a pair of required allowable paths.

Many key value grammars enforce key uniqueness within a range. For example, in JSON, it may be assumed that the keys are unique within the JSON object, even though there may be duplicate keys across the object. This two-stage parsing of the grammar can be reduced to parse substrings. Specifically, Trans extracts the continuous substring R 'from R so that the range of a pair can be correctly determined even within R'. For example, in JSON, if

If and only returns true if R is a prefix of R, then only R is resolved to JSON until a yield R is generated _{Open and open} Is sufficient to determine the character string R _{Open and open} Whether or not to correspond to the correct context in R.

Syntax with unique key at a given key value

In this case, we define a function that checks the uniqueness of the key, denoted as

In a given character string

And another string k, if and only if there is at most one resolvableStart ofkIntermediate (II)When the sub-string of s is used,

due to the fact that

This means that in any parse tree of s there is at most one branch with node keys and derivation k. Suppose that

For inputting at grammar

Returns the true function. If for all

And all the possible keys k are used,

then we say the grammar

For a key value syntax with a unique key, i.e., for all strings R, C:

specific two-stage parsing for unique key syntax hypothesis

Is a unique key syntax as given above. Let us assume that

Is LL (1). This is the case for example for the syntax of interest described previously. The generic LL (1) parsing algorithm is known.

We target a set of T pairs context functions

Is instantiated such that T is contained in

The allowable path of the pairing of the character strings in (1). We furthermore allow

Taking as input an auxiliary limit, said auxiliary limit being the key k: (

Output R of _{Open and open} The specified key in (1). The tuple (T, k) is denoted S and

suppose that

Is rule by

Wherein the pair is for

Is not at the end of the generation rule, and

is composed of

The start symbol in (1). We will want to

Defined as a function that determines whether a string s is present

And if so, whether the key in s is equal to k. At input R, R _{Open and open} In the above-mentioned manner,

(a) by running

Examination of R _{Open and open} Checking R for a valid key-value pair (b) with key k by running LL (1) parsing algorithm to parse R _{Open and open} Resolve to a key value pair in R.

FIG. 14 shows a function for

In a key value syntax

In parsing a string R and searching for a specific key value pair R _{Open and open} The generated example pseudo code. Will be used herein as

LL (1)) PTable hard-decoding of analysis table

To make pairs on a long character string R

In order to extract the substring R ' of R, we introduce a transformation Trans such that R ' is R ' on demand _{Open by opening} 。

For the string s, t, we also define a function substring (s, t) that returns true in the case of a substring where t is s, and an equality (s, t) that returns true in the case of s-t. We define with rules

And

meaning that, each time equal (R', R) _{Open and open} ) Time-piece

And rule

For all character strings R', S _{Open by opening} Is true.

It can be shown that the display device can display,

is true with respect to R. More particularly, if R' is a substring of R, then the key value pair R _{Open and open} By

Resolution, then the same pair is defined as

The substring of (2). Due to the fact that

Of the key of (1), there being only one such pairing R _{Open by opening} And is

Must be true.

The additional protocol details above, similar to those described elsewhere herein, are presented merely as illustrative examples and are not intended to be limiting in any way. Other embodiments may utilize alternative protocol arrangements to implement decentralized oracle machines as disclosed herein.

As indicated above, illustrative embodiments of a decentralized prophetic machine as disclosed herein may be implemented in a wide variety of different applications.

For example, DECO can be used to implement a personal data market, where users control and sell their personal data. It is well known that web services benefit from monetizing user data. A personal data marketplace implemented using the techniques disclosed herein may corrupt this data by enabling users to sell their data in an open marketplace. In the illustrative embodiment, DECO is a key enabler for the personal data market, as DECO enables buyers to verify the source and integrity of data from websites. DECO also allows sellers to pre-process data, such as revision sensitive information, for privacy protection while preventing seller cheating. Some embodiments utilize DECO to provide verifiable statements for price discrimination.

As another example, DECO may be used to provide proof of financial reimbursement capabilities. As a more specific illustration of this type of arrangement, using DECO, Alice can prove to Bob that her balance at a particular bank exceeds $ 5000. This simple proof shows not only Alice's financial reimbursement capability, but also her ability to open an account (e.g., Alice is not on any sanctioning list while the bank is screening for anti-money laundering (AML)). Importantly, DECO protects her privacy by only revealing Alice's balance above $5,000, not her actual balance or identity.

As another example, DECO may be used to provide proof of account ownership. In one illustration of such an arrangement, ownership of an account (e.g., an email account, social media account, etc.) may be anonymously attested using DECO. For example, Alice may prove to Bob that she owns an email account ending with @ example. This demonstrates the Alice's contact with an organization, which is useful for, e.g., reporting, anonymous complaints, etc.

Additional examples of applications of a decentralized oracle as disclosed herein include credential recovery and decentralized identity. As an illustration of the former, DECO may enable a user to prove that she has access to a particular network resource, such as a Facebook account, in a privacy-preserving manner that avoids the use of OAUTH. This may enable a user to prove her identity with an existing service for key recovery, for example. As an illustration of the latter, DECO may also enable a user to prove in a privacy-preserving manner that she has certain features certified by a third-party provider (e.g., she is 18 years old). This is an example of what is also referred to herein as anonymous age attestation. Such proof can be used to construct credentials in a decentralized identity system.

The aforementioned decentralized prophetic application is merely an example and should not be construed as limiting in any way. Additional details regarding the implementation of these and other example applications of the decentralized propheter as disclosed herein may be found elsewhere herein.

Assume that communications between various elements of an information processing system configured to implement one or more decentralized oracle as disclosed herein are conducted via one or more networks. A given such network may illustratively include, for example: a global computer network, such as the Internet, WAN, LAN, satellite network, telephone or cable television network; cellular networks, such as 3G, 4G or 5G networks; wireless networks implemented using wireless protocols such as bluetooth, WiFi, or WiMAX, or various portions or combinations of these and other types of communication networks.

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

It should be understood that the particular arrangements shown and described herein in connection with fig. 1-14 are presented as illustrative examples only, and that numerous alternative embodiments are possible. The various embodiments disclosed herein are therefore not to be construed as limiting in any way. In other embodiments, numerous alternative arrangements for implementing a decentralized oracle may be utilized. For example, those skilled in the art will recognize that alternative processing operations and associated system entity configurations may be used in other embodiments. It is thus possible that other embodiments may include additional or alternative system entities with respect to the entities of the illustrative embodiments. Moreover, in other embodiments, the particular system and device configurations and associated decentralized oracle may vary.

It should also be noted that the information handling system arrangement described above is merely exemplary, and that alternative system arrangements may be used in other embodiments.

A given client, server, processor, or other component in an information handling system as described herein is illustratively configured to utilize a corresponding processing device that includes a processor coupled to a memory. The processor executes software program code stored in the memory to control the performance of processing operations and other functionality. The processing device also includes a network interface that supports communication via one or more networks.

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

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

Articles of manufacture that include such processor-readable storage media are considered embodiments of the invention. The term "article of manufacture" as used herein should be understood to not include a transitory propagating signal.

In other embodiments, other types of computer program products comprising a processor-readable storage medium may be implemented.

Additionally, embodiments of the invention may be implemented in the form of an integrated circuit that includes processing circuitry configured to implement processing operations associated with the decentralized oracle and other related functionality.

The processing devices in a given embodiment may include, for example, a laptop computer, a tablet computer or a desktop personal computer, a mobile phone, or other type of computer or communication device, in any combination. For example, a computer or mobile phone may be used as a processing device for implementing at least part of the functionality associated with a decentralized prognostics as disclosed herein. These and other communications between various elements of an information handling system, including processing devices associated with respective system entities, may occur via one or more networks.

An information handling system as disclosed herein may be implemented using one or more processing platforms, or portions thereof.

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

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

Another illustrative embodiment of a processing platform that may be used to implement at least a portion of an information handling system as disclosed herein comprises a plurality of processing devices in communication with each other via at least one network. Assume that each processing device of the processing platform includes a processor coupled to a memory.

Again, these particular processing platforms are presented by way of example only, and the information handling system may include additional or alternative processing platforms, as well as numerous different processing platforms in any combination, where each such platform includes one or more computers, servers, storage devices, or other processing devices.

For example, other processing platforms for implementing embodiments of the invention may include different types of virtualization infrastructure in place of or in addition to virtualization infrastructure that includes virtual machines. Thus, in some embodiments, it is possible that the system components may run at least partially in a cloud infrastructure or other type of virtualization infrastructure, including virtualization infrastructure utilizing a Docker container or other type of Linux container implemented using operating system level virtualization based on a Linux control group or other similar mechanism.

Thus, 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.

In addition, many other arrangements of computers, servers, storage devices, or other components in an information handling system are possible. Such components may communicate with other elements of the information handling system via any type of network or other communication medium.

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

The particular configuration of information handling systems described herein is merely exemplary, and given such systems may in other embodiments include other elements in addition to or instead of the elements specifically shown, including one or more elements of the type commonly found in conventional implementations of such systems.

For example, in some embodiments, an information handling system may be configured to utilize the disclosed techniques to provide additional or alternative functionality in other contexts.

Thus, the techniques described in the context of providing a decentralized oracle for TLS in some embodiments herein may be adapted in a straightforward manner for use in other contexts. Thus, the illustrative embodiments of the present invention should not be considered limited to TLS or its associated processing context.

It should also be understood that the particular process steps used in the embodiments described herein are merely exemplary, and other embodiments may utilize different types and arrangements of processing operations. For example, certain process steps shown as occurring in succession in an illustrative embodiment may, in other embodiments, occur at least partially in parallel with one another.

It should be emphasized again that the embodiments of the present invention as described herein are intended to be illustrative only. Other embodiments of the invention may be implemented using information handling systems, networks, and devices of a different type and arrangement than those used in the particular illustrative embodiments described herein and in numerous alternative processing contexts. In addition, certain assumptions made herein in the context of describing certain embodiments need not apply in other embodiments. These and numerous other alternative embodiments will be readily apparent to those skilled in the art.

Claims (25)

1. An apparatus, comprising:

a verifier device comprising a processor coupled to a memory;

the verifier device is configured to communicate with a client device and a server device via one or more networks;

wherein the verifier device is further configured to:

participating in a three-way handshake protocol with the client device and the server device, wherein the authenticator device and the client device obtain respective shares of a session key for a secure session with the server device;

receiving, from the client device, a submission related to the secure session of the server device;

in response to receiving the submission, releasing additional information related to the secure session previously inaccessible to the client device; and

verifying a correctness of at least one characterization of data obtained by the client device from the server device as part of the secure session based at least in part on the submission and the additional information.

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

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

4. The apparatus of claim 1, wherein the verifier device comprises a distributed verifier device, wherein functionality of the verifier device is distributed across a plurality of distinct processing devices.

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

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

7. The apparatus of claim 1, wherein the submission relating to the secure session comprises a submission of a prover key established by the client device in conjunction with the three-way handshake protocol but previously inaccessible by the authenticator device.

8. The apparatus of claim 1, wherein the additional information released to the client device in response to receiving the submission comprises an authenticator key established by the authenticator device in conjunction with the three-way handshake protocol but previously inaccessible by the client device.

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

10. The apparatus of claim 1, wherein the authenticator 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.

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

12. The apparatus of claim 10, wherein a given one of the one or more statements is configured to provide contextual integrity by utilizing a multi-phase resolution protocol in which query response data obtained by the client device from the server device as part of the secure session is pre-processed by the client device to produce reduced data that is subsequently resolved by the client device in connection with production of the given statement to be sent by the client device to the verifier device.

13. The apparatus of claim 1, wherein in conjunction with the three-way handshake protocol, the client device and the authenticator device jointly establish one or more shared session keys with the server device, wherein the client device has a first share of a given one of the one or more shared session keys, the authenticator device has a second share of the given shared session key, and the server device has a composite session key that combines the first share and the second share.

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

15. The apparatus of claim 1, wherein the authenticator device and the client device cooperate using their respective shares of the session key for the secure session with the server device to generate a query provided by the client device to the server device to request the server device to send the data to the client device.

16. The apparatus of claim 15, wherein the authenticator device and the client device cooperate using their respective shares of the session key of the secure session with the server device to authenticate a response provided by the server device to the client device in response to the query.

17. The apparatus of claim 1, wherein in conjunction with the three-way handshake protocol, the client device and the verifier device establish respective prover and verifier keys.

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

19. The apparatus of claim 1, wherein verifying correctness of at least one characterization of data obtained by the client device from the server device as part of the secure session comprises:

obtaining data derived from at least a portion of at least one ciphertext of the secure session; and

verifying, by the client device, correctness of at least one characterization of the data.

20. A method by a verifier device configured to communicate with a client device and a server device over one or more networks, the method comprising:

participating in a three-way handshake protocol with the client device and the server device, wherein the verifier device and the client device obtain respective shares of a session key for a secure session with the server device;

receiving, from the client device, a submission related to the secure session of the server device;

in response to receiving the submission, releasing additional information related to the secure session that was previously inaccessible to the client device; and

verifying correctness of at least one characterization of data obtained by the client device from the server device as part of the secure session based at least in part on the submission and the additional information;

wherein the verifier device performing the method comprises a processor coupled to a memory.

21. The method of claim 20, wherein verifying correctness of at least one characterization of data obtained by the client device from the server device as part of the secure session comprises:

obtaining data derived from at least a portion of at least one ciphertext of the secure session; and

verifying, by the client device, correctness of at least one characterization of the data.

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

23. A computer program product comprising a non-transitory processor-readable storage medium having stored therein program code of one or more software programs, wherein the program code, when executed by a verifier device configured to communicate with a client device and a server device over one or more networks, causes the verifier device to:

participating in a three-way handshake protocol with the client device and the server device, wherein the authenticator device and the client device obtain respective shares of a session key for a secure session with the server device;

receiving, from the client device, a submission related to the secure session of the server device;

in response to receiving the submission, releasing additional information related to the secure session that was previously inaccessible to the client device; and

verifying a correctness of at least one characterization of data obtained by the client device from the server device as part of the secure session based at least in part on the submission and the additional information.

24. The computer program product of claim 23, wherein verifying correctness of at least one characterization of data obtained by the client device from the server device as part of the secure session comprises:

obtaining data derived from at least a portion of at least one ciphertext of the secure session; and

verifying, by the client device, correctness of at least one characterization of the data.

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

Images