Patent Application
20250088516
The field relates generally to information security, including, for example, techniques for proving that data is from a particular source or otherwise verifying correctness of data obtained in the context of transport layer security (TLS) and in other contexts.
Thanks to the widespread deployment of TLS, users can access private data over channels with end-to-end confidentiality and integrity. What they cannot do, however, is prove to third parties the provenance of such data, i.e., that it genuinely came from a particular website. Existing approaches either introduce undesirable trust assumptions or require server-side modifications. As a result, the value of users' private data is locked up in its point of origin.
Illustrative embodiments provide decentralized oracles for TLS and in numerous other applications in which it is necessary or otherwise desirable to prove that data is from a particular source.
For example, some embodiments overcome the above-described disadvantages of existing approaches by providing a decentralized oracle, illustratively referred to herein as DECO, that allows users to prove that a piece of data accessed via TLS came from a particular website, and to optionally prove statements about such data in zero-knowledge, keeping the data itself secret. DECO can thus liberate data from centralized web-service silos, making it accessible to a rich spectrum of applications. Advantageously, DECO in illustrative embodiments works without trusted hardware or server-side modifications.
In one embodiment, an apparatus comprises a verifier device that includes a processor and a memory coupled to the processor. The verifier device is configured to communicate over one or more networks with a client device and a server device. The verifier device participates in a three-party handshake protocol with the client device and the server device in which the verifier device and the client device obtain respective shares of a session key of a secure session with the server device. The verifier device receives from the client device a commitment relating to the secure session with the server device, and responsive to receipt of the commitment, releases to the client device additional information relating to the secure session that was not previously accessible 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 commitment and the additional information.
It is to be appreciated that the foregoing arrangements are only examples, and 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.
Embodiments of the invention can be implemented, for example, in the form of information processing systems comprising computer networks or other arrangements of networks, clients, servers, processing devices and other components. Illustrative embodiments of such systems will be described in detail herein. It should be understood, however, that embodiments of the invention are more generally applicable to a wide variety of other types of information processing systems and associated networks, clients, servers, processing devices or other components. Accordingly, the term “information processing system” as used herein is intended to be broadly construed so as to encompass these and other arrangements.
The network 105 can illustratively include, for example, a global computer network such as the Internet, a wide area network (WAN), a local area network (LAN), a satellite network, a telephone or cable network, a cellular network such as a third generation (3G), fourth generation (4G) or fifth generation (5G) network, a wireless network implemented using a wireless protocol such as Bluetooth, WiFi or WiMAX, or various portions or combinations of these and other types of communication networks.
The system 100 further comprises a plurality of TLS servers 106 associated with respective protected data sources 108. The TLS servers 106 are illustratively configured to control access to their respective protected data sources 108. At least a subset of the protected data sources 108 illustratively comprise respective HTTPS-enabled websites, where HTTPS denotes Hypertext Transfer Protocol Secure, an extension of the Hypertext Transfer Protocol (HTTP). It is to be appreciated that a wide variety of additional or alternative data sources can be used in other embodiments. The protected data sources 108 of the system 100 are protected in the sense that they can be securely accessed via HTTPS through at least one of the TLS servers 106. Other data sources need not be accessible in this particular manner, and can implement additional or alternative access control mechanisms, and/or could be publicly accessible using other types of secure protocols.
Also, although illustrative embodiments herein utilize one or more servers of particular types, such as TLS servers 106, it is to be appreciated that other types of secure protocols can be used in other embodiments, and can be implemented in other types of server devices. The term “server device” as used herein is therefore intended to be broadly construed, and should not be viewed as being limited in any way to TLS servers.
The client devices 102 in some embodiments operate as respective prover devices relative to the verifier device 104 or other zero knowledge proof (ZKP) oracle nodes 110 of system 100. The verifier device 104 may therefore be viewed as a ZKP oracle node of the system 100. Accordingly, a given “verifier device” as that term is broadly used herein can comprise, for example, a particular oracle node of a set of oracle nodes of a decentralized oracle system such as system 100.
The particular numbers, types and arrangements of devices and other components in system 100 are presented by way of illustrative example only, and can be varied in other embodiments. For example, although only a single verifier device 104 is shown in this embodiment, other embodiments can include multiple verifier devices, as in an arrangement in which the other ZKP oracle nodes 110 operate as respective verifier devices. Also, one or more of the TLS servers 106 can each be configured to control access to multiple ones of the protected data sources 108. Numerous other decentralized oracle arrangements are possible.
The verifier device 104 comprises a three-party handshake module 112, a post-handshake interaction module 114, and a proof verification module 116. These modules implement respective distinct protocols of a decentralized oracle protocol, also referred to herein as a DECO protocol, as described in more detail below.
The verifier device 104 in the present embodiment further comprises a processor 120, a memory 122 and a network interface 124. The processor 120 is assumed to be operatively coupled to the memory 122 and to the network interface 124 via the simplified illustrative interconnections shown in the figure.
The processor 120 may comprise, for example, a microprocessor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a central processing unit (CPU), a graphics processing unit (GPU), an arithmetic logic unit (ALU), a digital signal processor (DSP), or other similar processing device component, as well as other types and arrangements of processing circuitry, in any combination. At least a portion of the functionality of a decentralized oracle provided by a given processing device as disclosed herein can 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 portions of the functionality of the modules 112, 114 and 116 can be implemented using program code stored in memory 122.
A given such memory that 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 static random access memory (SRAM), dynamic random access memory (DRAM) or other types of random access memory (RAM), read-only memory (ROM), flash memory, magnetic memory, optical memory, or other types of storage devices in any combination.
Articles of manufacture comprising such processor-readable storage media are considered embodiments of the invention. The term “article of manufacture” as used herein should be understood to exclude transitory, propagating signals.
Other types of computer program products comprising processor-readable storage media can be implemented in other embodiments.
In addition, embodiments of the invention may be implemented in the form of integrated circuits comprising processing circuitry configured to implement processing operations associated with one or more of the client devices 102, verifier device 104, TLS servers 106 and other ZKP oracle nodes 110.
The network interface 124 is configured to allow the verifier device 104 to communicate over the network 105 with other system elements, and may comprise one or more conventional transceivers.
In operation, the verifier device 104 in illustrative embodiments is configured to participate in a three-party handshake protocol with a given one of the client devices 102, such as client device 102-1, and a given one of the TLS servers 106. Such participation is illustratively controlled by the three-party handshake module 112 of the verifier device 104. In conjunction with execution of the three-party handshake protocol, verifier device 104 and the client device 102-1 obtain respective shares of a session key of a secure session with the given TLS server. The secure session illustratively comprises a TLS session.
The verifier device 104 receives from the client device 102-1 a commitment relating to the secure session with the given TLS server. Responsive to receipt of the commitment, the verifier device 104 releases to the client device 102-1 additional information relating to the secure session that was not previously accessible to the client device 102-1. These operations relating to the commitment are illustratively performed 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 the given TLS server as part of the secure session, based at least in part on the commitment and the additional information. Such verification is illustratively performed under the control of the proof verification module 116.
In some embodiments, the verifier device 104 is further configured to initiate one or more automated actions responsive to the verification of the correctness of the at least one characterization of the data obtained by the client device 102-1 from the given TLS server. For example, the verifier device 104 can return verification information or other related information to the client device 102-1.
By way of example, the commitment relating to the secure session may comprise a commitment to query response data obtained by the client device 102-1 from the given TLS server as part of the secure session.
As another example, the commitment relating to the secure session may comprise a commitment to a prover key established by the client device 102-1 in conjunction with the three-party handshake protocol but not previously accessible to the verifier device 104. Other types of commitments can be used in other embodiments.
The additional information released to the client device 102-1 responsive to receipt of the commitment in some embodiments comprises a verifier key established by the verifier device 104 in conjunction with the three-party handshake protocol but not previously accessible to 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 interactions between the client device 102-1 and the given TLS server, such that the verifier device 104 automatically obtains ciphertexts exchanged between the client device 102-1 and the given TLS server as part of the secure session via the verifier device 104 operating as the proxy. Such an embodiment is referred to herein as a “proxy mode” arrangement.
The verifier device 104 in some embodiments is further configured to receive from the client device 102-1 one or more statements characterizing the data obtained by the client device 102-1 from the given TLS server as part of the secure session.
For example, a given one of the one or more statements illustratively comprises a selectively-revealed substring of query response data obtained by the client device 102-1 from the given TLS server as part of the secure session.
As another example, a given one of the one or more statements is illustratively configured to provide context integrity through utilization of a multi-stage parsing protocol in which query response data obtained by the client device 102-1 from the given TLS server as part of the secure session is preprocessed by the client device 102-1 to generate reduced data that is subsequently parsed by the client device 102-1 in conjunction with 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 the data obtained by the client device 102-1 from the given TLS server as part of the secure session can be used in other embodiments.
In some embodiments, in conjunction with the three-party handshake protocol, the client device 102-1 and the verifier device 104 jointly establish one or more shared session keys with the given TLS server, with the client device 102-1 having a first share of a given one of the one or more shared session keys, the verifier device 104 having a second share of the given shared session key, and the given TLS server having a composite session key combining the first and second shares.
Additionally or alternatively, in conjunction with the three-party handshake protocol, the client device 102-1 receives from the given TLS server an encryption key that is not accessible to the verifier device 104.
In some embodiments, the verifier device 104 and the client device 102-1 collaborate using their respective shares of the session key of 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 that the given TLS server send the data to the client device 102-1.
The verifier device 104 and the client device 102-1 can similarly collaborate using their respective shares of the session key of the secure session with the given TLS server to validate a response that is provided by the given TLS server to the client device 102-1 responsive to the query.
In some embodiments, in conjunction with the three-party handshake protocol, the client device 102-1 and the verifier device 104 establish respective prover and verifier keys. In such an embodiment, verifying correctness of at least one characterization of data obtained by the client device 102-1 from the given TLS server as part of the secure session illustratively comprises verifying a proof provided by client device 102-1 to the verifier device 104. The proof is illustratively generated by the client device 102-1 based at least in part on (i) the prover key established by the client device 102-1 in conjunction with the three-party handshake protocol, (ii) the verifier key established by the verifier device 104 in conjunction with the three-party handshake protocol, and (iii) secret information of the client device 102-1, such as a password or passcode.
In some embodiments, verifying correctness of at least one characterization of data obtained by the client device 102-1 from the given TLS server as part of the secure session illustratively comprises obtaining data derived from at least a portion of at least one ciphertext of the secure session, and verifying correctness of at least one characterization of that data by the client device 102-1. The term “ciphertext” as used in this context and elsewhere herein is intended to be broadly construed, and should not be viewed as requiring the use of any particular cryptographic protocol.
It is to be appreciated that the particular arrangement of components and other system elements shown in
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, the verifier device in other embodiments can comprise a distributed verifier device in which functionality of the verifier device 104 is distributed across multiple distinct processing devices. In such embodiments, the role of the verifier in various protocols disclosed herein can be distributed across multiple distinct parties executing a multi-party protocol, with each such party being associated with a different one of the multiple processing devices of the distributed verifier device. The term “device” as used herein is therefore intended to be broadly construed, so as to encompass at least one processing device comprising a processor coupled to a memory, and therefore multiple such processing devices as in the case of the distributed verifier device.
In this embodiment, the process illustratively comprises steps 200 through 208. As noted above, at least portions of these steps are assumed to be performed at least in part by 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 in the context of the
In step 200, the verifier participates in a three-party handshake protocol with the client and the server, with the client acting as the prover.
In step 202, in conjunction with the three-party handshake protocol, the verifier and the prover obtain respective shares of a session key of a secure session with the server.
In step 204, the verifier receives from the prover a commitment relating to the secure session with the server.
In step 206, responsive to receipt of the commitment, the verifier releases to the prover additional information relating to the secure session that was not previously accessible to the prover.
In step 208, the verifier verifies correctness of at least one characterization of data obtained by the prover from the server as part of the secure session, based at least in part on the commitment and the additional information.
Numerous other techniques can be used in association with implementation of decentralized oracles as disclosed herein.
Accordingly, the particular processing operations and other functionality described in conjunction with the flow diagram of
Additional aspects of illustrative embodiments will now be described with reference to
The widespread deployment of TLS allows users to access private data over channels with end-to-end confidentiality and integrity. What they cannot readily do under conventional practice, however, is prove to third parties the provenance of such data, i.e., that it genuinely came from a particular website. Existing approaches either introduce undesirable trust assumptions or require server-side modifications.
As a result, users' private data is locked up at its point of origin. Users cannot export their data in an integrity-protected way to other applications without help and permission from the current data holder.
Illustrative embodiments herein provide techniques referred to as DECO (short for decentralized oracle) to address these and other problems. DECO allows users to prove that a piece of data accessed via TLS came from a particular website and optionally prove statements about such data in zero-knowledge, keeping the data itself secret. Advantageously, DECO in illustrative embodiments can be implemented without the need for trusted hardware or server-side modifications.
DECO can liberate data from centralized web-service silos, making it accessible to a rich spectrum of applications. To demonstrate the power of DECO, we implement three applications that are hard to achieve without it: a private financial instrument using smart contracts, converting legacy credentials to anonymous credentials, and verifiable claims against price discrimination.
It is to be appreciated that these and other references to DECO herein refer to illustrative embodiments, and the particular features, functionality, advantages and other details of those embodiments should not be construed as limiting in any way. Alternative embodiments can implement additional or alternative 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 web data over confidential, integrity-protected channels. But TLS has a serious limitation: it doesn't allow a user to prove to third parties that a piece of data she has accessed authentically came from a particular website. As a result, data use is often restricted to its point of origin, curtailing data portability by users, a right acknowledged by recent regulations such as the General Data Protection Regulation (GDPR).
Specifically, when a user accesses data online via TLS, she cannot securely export it, without help (hence permission) from the current data holder. Vast quantities of private data are thus intentionally or unintentionally locked up in the “deep web”—the part of the web that isn't publicly accessible.
To better appreciate the problem, consider an example in which Alice wants to prove to Bob that she's over 18. Currently, age verification services typically require users to upload IDs and detailed personal information, which raises privacy concerns. But various websites, such as company payroll records or Department of Motor Vehicles (DMV) websites, in principle store and serve verified birth dates. Alice could send a screenshot of her birth date from such a site, but this is easily forged. And even if the screenshot could somehow be proven authentic, it would leak information—revealing her exact birth date, not just that she's over 18.
Initially proposed to prove provenance of online data to smart contracts, oracles are a step towards exporting TLS-protected data to other systems with provenance and integrity assurances. Existing schemes, however, have serious technical limitations. They either only work with deprecated TLS versions and offer no privacy from the oracle (e.g., TLSNotary) or rely on trusted hardware (e.g., Town Crier), against which various attacks have recently emerged. Another class of oracle schemes assumes server-side cooperation, mandating that servers install TLS extensions or change application-layer logic. Server-facilitated oracle schemes suffer from two fundamental problems. First, they break legacy compatibility, causing a significant barrier to wide adoption. Moreover, such solutions only provide conditional exportability because the web servers have the sole discretion to determine which data can be exported, and can censor export attempts at will. A mechanism that allows users to export any data they have access to would enable a whole host of currently unrealizable applications.
To address the above problems, illustrative embodiments disclosed herein provide an arrangement referred to as DECO, a decentralized oracle for TLS. Unlike oracle schemes that require per-website support, DECO is illustratively source-agnostic and supports any website running standard TLS. Unlike solutions that rely on websites' participation, DECO requires no server-side cooperation. Thus a single instance of DECO could enable anyone to become an oracle for any website.
DECO makes rich Internet data accessible with authenticity and privacy assurances to a wide range of applications, including ones that cannot access the Internet such as smart contracts. DECO could fundamentally shift today's model of web data dissemination by providing private data delivery with an option for transfer to third parties or public release. This technical capability highlights potential future legal and regulatory challenges, but also anticipates the creation and delivery of appealing new services. Importantly, DECO does not require trusted hardware, unlike some alternative approaches.
In some embodiments, at a high level, the prover commits to a piece of data D and proves to the verifier that D came from a TLS server
and optionally a statement πD about D. With reference again to the example of proving age, the statement πD could be the predicate “D=y/m/d is Alice's date of birth and the current date—D is at least 18 years.”
Informally, DECO achieves authenticity—that the verifier is convinced only if the asserted statement about D is true and D is indeed obtained from TLS server . DECO also provides privacy in that the verifier only learns that the statement πD holds for some D obtained from
.
Designing DECO with the required security and practical performance, while using legacy TLS compatible primitives, introduces several important technical challenges. One challenge stems from the fact that TLS generates symmetric encryption and authentication keys that are shared by the client (e.g., prover in DECO) and web server. Thus, the client can forge arbitrary TLS session data, in the sense of signing the data with valid authentication keys.
To address this challenge, DECO introduces a novel three-party handshake protocol among the prover, verifier, and web server that creates an unforgeable commitment by the prover to the verifier on a piece of TLS session data D. The verifier can check that D is authentically from the TLS server. From the prover's perspective, the three-party handshake preserves the security of TLS in the presence of a malicious verifier.
Efficient selective opening. After committing to D, the prover proves statements about the commitment. Although arbitrary statements can be supported in theory, we optimize for what are likely to be the most popular applications—revealing only substrings of the response to the verifier. We call such statements selective opening. Fine-grained selective opening allows users to hide sensitive information and reduces the input length to the subsequent proofs.
A naïve solution would involve expensive verifiable decryption of TLS records using generic zero-knowledge proofs (ZKPs), but illustrative embodiments herein achieve an orders-of-magnitude efficiency improvement by exploiting the TLS record structure. For example, a direct implementation of verifiable decryption of a TLS record would involve proving correct execution of a circuit of 1024 Advanced Encryption Standard (AES) invocations in zero-knowledge, whereas by leveraging the Message Authentication Code-then-encrypt (MAC-then-encrypt) structure of Cipher Block Chaining-Hash-based Message Authentication Code (CBC-HMAC), illustrative embodiments herein can accomplish the same with only 3 AES invocations.
Context integrity. Selective opening allows the prover to only reveal a substring D′ of the server's response D. However, a substring may mean different things depending on when it appears and a malicious prover could cheat by quoting out of context. Therefore we need to prove not just that D′ appears in D, but that it appears in the expected context, i.e., D′ has context integrity with respect to D. (Note that this differs from “contextual integrity” in privacy theory.)
Context-integrity attacks can be thwarted if the session content is structured and can be parsed. Fortunately most web data takes this form (e.g., in JavaScript Object Notation (JSON) or Hypertext Markup Language (HTML)). A generic solution is to parse the entire session and prove that the revealed part belongs to the necessary branch of a parse tree. But, under certain constraints that web data generally satisfies, parsing the entire session is not necessary. Some embodiments disclosed herein provide a novel two-stage parsing scheme where the prover pre-processes the session content, and only parses the outcome that is usually much smaller. We draw from the definition of equivalence of programs, as used in programming language theory, to build a formal framework to reason about the security of two-stage parsing schemes. Illustrative embodiments disclosed herein provide several practical realizations for specific grammars. Our definitions and constructions generalize to other oracles too. For example, it could prevent a generic version of a content-hidden attack.
With regard to implementation and evaluation of illustrative embodiments, we designed and implemented DECO as a complete end-to-end system. To demonstrate the system's power, we implemented three applications: 1) a confidentiality-preserving financial instrument using smart contracts; 2) converting legacy credentials to anonymous credentials; and 3) verifiable claims against price discrimination.
Our experiments with these applications show that DECO is highly efficient. For example, for TLS 1.2 in the WAN setting, online time is 2.85s to perform the three-party handshake and 2.52s for 2PC query execution. It takes about 3s to 13s to generate zero-knowledge proofs for the applications described above. More details are provided elsewhere herein.
DECO as disclosed in conjunction with illustrative embodiments to be described in detail below advantageously provides a provably secure decentralized oracle scheme. DECO in some embodiments provides an oracle scheme for modern TLS versions that doesn't require trusted hardware or server-side modifications.
We also describe in detail below a broad class of statements for TLS records that can be proven efficiently in zero-knowledge using DECO. Such statements allow users to open only substrings of a session-data commitment. The optimizations achieve substantial efficiency improvement over generic ZKPs.
With regard to context-integrity attacks and mitigation, we identify a new class of context-integrity attacks universal to privacy-preserving oracles, and we describe our mitigation approach involving a novel, efficient two-stage parsing scheme.
We now provide some background on TLS handshake and record protocols on which DECO builds in illustrative embodiments.
TLS is a family of protocols that provides privacy and data integrity between two communicating applications. Roughly speaking, it consists of two protocols: a handshake protocol that sets up the session using asymmetric cryptography, establishing shared client and server keys for the next protocol, the record protocol, in which data is transmitted with confidentiality and integrity protection using symmetric cryptography.
Handshake. In the handshake protocol, the server and client first agree on a set of cryptographic algorithms (also known as a cipher suite). They then authenticate each other (client authentication optional), and finally securely compute a shared secret to be used for the subsequent record protocol.
DECO in illustrative embodiments utilizes elliptic curve Diffie-Hellman (DH) key exchange with ephemeral secrets (ECDHE), although this is by way of example rather than limitation.
Record Protocol. To transmit application-layer data (e.g., HTTP messages) in TLS, the record protocol first fragments the application data D into fixed sized plaintext records D=(D1, . . . , Dn). Each record is usually padded to a multiple of blocks (e.g., 128 bits). The record protocol then optionally compresses the data, applies a MAC, encrypts, and transmits the result. Received data is decrypted, verified, decompressed, reassembled, and then delivered to higher-level protocols. The specific cryptographic operations depend on the negotiated cipher suite. DECO supports the Advanced Encryption Standard (AES) cipher in two commonly used modes: CBC-HMAC and GCM, where CBC-HMAC denotes Cipher Block Chaining-Hash-based Message Authentication Code, and GCM denotes Galois/Counter Mode. Additional details regarding these and other aspects of TLS can be found in, for example, T. Dierks and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, 2008, which is incorporated by reference herein. Again, other protocols can be used in other embodiments.
Differences Between TLS 1.2 and 1.3. In some embodiments herein we focus on TLS 1.2, and later describe how to generalize our techniques to TLS 1.3. Here we briefly note the major differences between these two TLS versions. TLS 1.3 removes the support for legacy non-authenticated encryption with additional data (non-AEAD) ciphers. The handshake flow has also been restructured. All handshake messages after the ServerHello are now encrypted. Finally, a different key derivation function is used. Additional details can be found in E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, 2018, which is incorporated by reference herein.
Consider a group of n parties 1, . . . ,
n, each of whom holds some secret si. Secure multi-party computation (MPC) allows them to jointly compute f (si, . . . , Sn) without leaking any information other than the output of f, i.e.,
learns nothing about Sj≠i. Security for MPC protocols generally considers an adversary that corrupts t players and attempts to learn the private information of an honest player. Two-party computation (2PC) refers to the special case of n=2 and t=1.
There are two general approaches to 2PC protocols. Garbled-circuit protocols encode f as a boolean circuit, an approach best-suited for bitwise operations (e.g., SHA-256 where SHA denotes Secure Hash Algorithm). Other protocols leverage threshold secret sharing and are best suited for arithmetic operations. The functions we compute in some embodiments using 2PC, though, include both bitwise and arithmetic operations. We separate them into two components, and use an optimized garbled-circuit protocol for the bitwise operations and a secret-sharing based multiplication-to-addition (MtA) protocol for the arithmetic operations. Additional details regarding an example optimized garbled-circuit protocol used in illustrative embodiments can be found in Xiao Wang, Samuel Ranellucci, and Jonathan Katz, “Authenticated Garbling and Efficient Maliciously Secure Two-Party Computation,” in Association for Computing Machinery Conference on Computer and Communications Security (ACM CCS), 2017, which is incorporated by reference herein. Additional details regarding an example secret-sharing based MtA protocol used in illustrative embodiments can be found in Rosario Gennaro and Steven Goldfeder, “Fast multiparty threshold ECDSA with fast trustless setup,” in ACM CCS, 2018, which is incorporated by reference herein. These are only examples, and other types of protocols can be used in other embodiments.
We now state a problem that is solved by illustrative embodiments of DECO and present a high-level overview of its architecture.
Illustrative embodiments herein provide protocols for building “oracles,” i.e., entities that can prove provenance and properties of online data. The goal is to allow a prover
to prove to a verifier
that a piece of data came from a particular website and optionally prove statements about such data in zero-knowledge, keeping the data itself secret. Accessing the data may require private input (e.g., a password) from
and such private information should be kept secret from
as well.
We focus in illustrative embodiments on servers running TLS, a widely deployed security protocol suite on the Internet. However, TLS alone does not prove data provenance. Although TLS uses public-key signatures for authentication, it uses symmetric-key primitives to protect the integrity and confidentiality of exchanged messages, using a shared session key established at the beginning of each session. Hence who knows this symmetric key, cannot prove statements about cryptographically authenticated TLS data to a third party.
A web server itself could assume the role of an oracle, e.g., by simply signing data. However, server-facilitated oracles would not only incur a high adoption cost, but also put users at a disadvantage: the web server could impose arbitrary constraints on the oracle capability. We are interested in a scheme where anyone can prove provenance of any data she can access, without needing to rely on a single, central point of control, such as the web server providing the data.
We address these and other challenges in illustrative embodiments by introducing what we refer to herein as “decentralized oracles” that don't rely on trusted hardware or cooperation from web servers. The problem is much more challenging than for previous oracles, as it precludes solutions that require servers to modify their code or deploy new software, or use of prediction markets, while at the same time going beyond these previous approaches by supporting proofs on arbitrary predicates over data.
Authenticated data feeds for smart contracts. An important application of illustrative embodiments disclosed herein is in constructing authenticated data feeds (ADFs), i.e., data with verifiable provenance and correctness, for smart contracts. A wide variety of other applications are advantageously supported by the techniques disclosed herein.
In the context of ADFs, since smart contracts can't participate in 2PC protocols, they must rely on oracle nodes to participate as on their behalf. Therefore, in some embodiments, we deploy DECO in a decentralized oracle network, where a set of independently operated oracles are available for smart contracts to use. Note that oracles running DECO are trusted only for integrity, not for privacy. Smart contracts can further hedge against integrity failures by querying multiple oracles and requiring, e.g., majority agreement. We emphasize that DECO's privacy is preserved even if all oracles are compromised. Thus DECO enables users to provide ADFs derived from private data to smart contracts while hiding private data from oracles.
In some embodiments, we use
to denote the prover,
the verifier and
the TLS server. We use letters in boldface (e.g., M) to denote vectors and Mi to denote the ith element in M.
We model the essential properties of an oracle using an ideal functionality Oracle as illustrated in
Oracle, all messages are tagged with a unique session id denoted sid. Additional or alternative oracle properties can be used in other embodiments.
As indicated in Oracle in this embodiment accepts a secret parameter θs (e.g., a password) from
, a query template Query and a statement Stmt from
. A query template is a function that takes
's secret θs and returns a complete query, which contains public parameters specified by
. An example query template would be Query(θs)=“stock price of GOOG on Jan. 1, 2020 with application programming interface (API) key=θs”. The prover
can later prove that the query sent to the server is well-formed, i.e., built from the template, without revealing the secret. The statement Stmt is a function that
wishes to evaluate on the server's response. Following the previous example, as the response R is a number, the following statement would compare it with a threshold: Stmt (R)=“R>$1,000”.
After
acknowledges the query template and the statement (by sending “ok” and θs), Oracle retrieves a response R from
using a query built from the template. We assume an honest server, so R is the ground truth. Oracle sends Stmt (R) and the data source to
.
We are interested in this embodiment in decentralized oracles that don't require any server-side modifications or cooperation, i.e.,
follows the unmodified TLS protocol. More particularly, a decentralized oracle protocol for TLS is a three-party protocol (Prot=,
,
) such that 1) Prot realizes
Oracle and 2)
is the standard TLS, possibly along with an application-layer protocol.
Adversarial Model and Security Properties. In illustrative embodiments, we consider a static, malicious network adversary . Corrupted parties may deviate arbitrarily from the protocol and reveal their states to
. As a network adversary,
learns the message length from Oracle since TLS is not length-hiding. We assume
and
choose and agree on an appropriate query (e.g., it should be idempotent for most applications) and statement according to the application-layer protocol run by .
For a given query , denote the server's honest response by
(). We require that security holds when either
or
is corrupted. The functionality Oracle reflects the following security guarantees:
We focus in illustrative embodiments on two widely used representative TLS cipher suites: CBC-HMAC and AES-GCM. Our technique generalizes to other ciphers (e.g., Chacha20-Poly1305, etc.) as well. We initially use CBC-HMAC to illustrate certain embodiments, and later describe the techniques for AES-GCM.
TLS uses separate keys for each direction of communication. Unless explicitly specified, we don't distinguish between the two and use kEnc and kMAC to denote session keys for both directions.
In presenting illustrative embodiments of DECO, we start with a strawman protocol and incrementally build up to the full protocol.
A strawman protocol that realizes Oracle between (
,
) is as follows.
queries the server
and records all messages sent to and received from the server in =(
1, . . . ,
n) and {circumflex over (R)}=({circumflex over (R)}1, . . . , {circumflex over (R)}n), respectively. Let {circumflex over (M)}=(
, {circumflex over (R)}) and (kMAC, kEnc) be the session keys.
She then proves in zero-knowledge that 1) each {circumflex over (R)}i decrypts to Ri∥σi, a plaintext record and a MAC tag; 2) each MAC tag σi for Ri verifies against kMAC; and 3) the desired statement evaluates to b on the response, i.e., b=Stmt(R). Using the standard notation,
computes
She also proves that
is well-formed as =Query (θs) similarly in a proof pq and sends (pq, pr, kMAC, {circumflex over (M)}, b) to
.
Given that {circumflex over (M)} is an authentic transcript of the TLS session, the prover-integrity property seems to hold. Intuitively, CBC-HMAC ciphertexts bind to the underlying plaintexts, thus {circumflex over (M)} can be treated as secure commitments to the session data. That is, a given {circumflex over (M)} can only be opened (i.e., decrypted and MAC checked) to a unique message. The binding property prevents
from opening {circumflex over (M)} to a different message other than the original session with the server.
Unfortunately, this intuition is flawed. The strawman protocol fails completely because it cannot ensure the authenticity of {circumflex over (M)}. The prover
has the session keys, and thus she can include the encryption of arbitrary messages in {circumflex over (M)}.
Moreover, the zero-knowledge proofs that
needs to construct involve decrypting and hashing the entire transcript, which can be prohibitively expensive. For the protocol to be practical, we need to significantly reduce the cost.
The critical failing of the above-described strawman approach is that
learns the session key before she commits to the session. In illustrative embodiments of DECO, the MAC key is withheld from
until after she commits.
The TLS session between
and the server
must still provide confidentiality and integrity. Moreover, the protocol must not degrade performance below the requirements of TLS (e.g., triggering a timeout).
, the verifier
, and the TLS server
establish session keys that are secret-shared between
and . After the handshake is a query execution phase during which
accesses the server following the standard TLS protocol, but with help from . After
commits to the query and response,
reveals her key share. Finally,
proves statements about the response in a proof generation phase.
Three-party handshake. Essentially,
and
jointly act as a TLS client. They negotiate a shared session key with
in a secret-shared form. We emphasize that this phase, like the rest of DECO, is completely transparent to , requiring no server-side modifications.
For the CBC-HMAC cipher suite, at the end of the three-party handshake,
and
receive
and
respectively, while
receives kMAC=+
. As with the standard handshake, both
and
get the encryption key kEnc.
The three-party handshake can make the aforementioned session-data commitment unforgeable as follows. At the end of the session,
first commits to the session in {circumflex over (M)} as before, then
reveals her share . From
's perspective, the three-party handshake protocol ensures that a fresh MAC key (for each direction) is used for every session, despite the influence of a potential malicious prover, and that the keys are unknown to
until she commits. Without knowledge of the MAC key,
cannot forge or tamper with session data before committing to it. The unforgeability of the session-data commitment in DECO thus reduces to the unforgeability of the MAC scheme used in TLS.
Other cipher suites such as GCM can be supported similarly. In GCM, a single key (for each direction) is used for both encryption and MAC. The handshake protocol similarly secret-shares the key between
and . The handshake protocol for GCM is described in more detail elsewhere herein.
Query execution. Since the session keys are secret-shared, as noted,
and
execute an interactive protocol to construct a TLS message encrypting the query.
then sends the message to
as a standard TLS client. For CBC-HMAC, they compute the MAC tag of the query, while for GCM they perform authenticated encryption. Note that the query is private to
and should not be leaked to . Generic 2PC would be expensive for large queries, so we instead introduce custom 2PC protocols that are orders-of-magnitude more efficient than generic solutions, as described elsewhere herein.
As explained previously,
commits to the session data {circumflex over (M)} before receiving 's key share, making the commitment unforgeable. Then
can verify the integrity of the response, and prove statements about it, as will now be described.
Proof generation. With unforgeable commitments, if
opens the commitment {circumflex over (M)} completely (i.e., reveals the encryption key) then
could easily verify the authenticity of {circumflex over (M)} by checking MACs on the decryption.
Revealing the encryption key for {circumflex over (M)}, however, would breach privacy: it would reveal all session data exchanged between
and . In theory,
could instead prove any statement Stmt over {circumflex over (M)} in zero knowledge (i.e., without revealing the encryption key). Generic zero-knowledge proof techniques, though, would be prohibitively expensive for many natural choices of Stmt. DECO instead introduces two techniques to support efficient proofs for a broad, general class of statement, namely what is referred to herein as “selective opening” of a TLS session transcript. Selective opening involves either revealing a substring to
or redacting, i.e., excising, a substring, concealing it from .
) wants to reveal his checking account balance to
. Revealing the decryption key for his TLS session would be undesirable: it would also reveal the entire statement, including his transactions. Instead, using techniques disclosed herein, Bob can efficiently reveal only the substring in lines 5-7. Alternatively, if he doesn't mind revealing his savings account balance, he might redact his transactions after line 7.
The two selective opening modes, revealing and redacting substrings, are useful privacy protection mechanisms. They can also serve as pre-processing for a subsequent zero-knowledge proof. For example, Bob might wish to prove that he has an account with a balance larger than $1000, without revealing the actual balance. He would then prove in zero knowledge a predicate (“balance >$1000”) over the substring that includes his checking account balance.
Selective opening alone, however, is not enough for many applications. This is because the context of a substring affects its meaning. Without what we call context integrity,
could cheat and reveal a substring that falsely appears to prove a claim to . For example, Bob might not have a balance above $1000. After viewing his bank statement, though, he might in the same TLS session post a message to customer service with the substring “balance”: $5000 and then view his pending messages (in a form of reflection attack). He could then reveal this substring to fool
.
Various sanitization heuristics on prover-supplied inputs to , e.g., truncating session transcripts, could potentially prevent some such attacks, but, like other forms of web application input sanitization, are fragile and prone to attack.
Instead, we introduce a rigorous technique by which session data are explicitly but confidentially parsed. We call this technique “zero-knowledge two-stage parsing.” In accordance with this technique,
parses {circumflex over (M)} locally in a first stage and then proves to
a statement in zero knowledge about constraints on a resulting substring. For example, in our banking example, if bank-supplied key-value stores are always escaped with a distinguished character λ, then Bob could prove a correct balance by extracting via local parsing and revealing to
a substring “balance”: $5000 preceded by λ. It can be shown that for a very common class of web API grammars (unique keys) this two-phase approach yields much more efficient proofs than more generic techniques.
The goal of the three-party handshake (3P-HS) in some embodiments is to secret-share between the prover
and verifier
the session keys used in a TLS session with server , in a way that is completely transparent to
. We first focus on CBC-HMAC for exposition, then adapt the protocol to support GCM.
Again, the particular details of these protocols are examples only, and not limiting in any way. For example, a wide variety of other types of three-party handshake protocols involving a prover, a verifier and a server can be used in other embodiments. The term “three-party handshake protocol” as used herein is therefore intended to be broadly construed.
As with the standard TLS handshake, 3P-HS includes two steps: first,
and
compute additive shares of a secret ZϵEC(p) shared with the server through a TLS-compatible key exchange protocol. ECDHE is recommended and the focus here, although other techniques can be used to compute shares; second,
and
derive secret-shared session keys by securely evaluating the TLS-PRF with their shares of Z as inputs, where PRF denotes pseudo random function. Below we give text descriptions so formal specifications are not required for understanding.
Step 1: key exchange. Let EC(p) denote the EC group used in ECDHE and G its generator.
The prover
initiates the handshake by sending a regular TLS handshake request and a random nonce rc to
(in the ClientHello message). On receiving a certificate, the server nonce rs, and a signed ephemeral DH public key =
·G from
(in the Server-Hello and ServerKeyExchange messages),
checks the certificate and the signature and forwards them to . After performing the same check,
samples a secret sV and sends her part of the DH public key YV=sV·G to , who then samples another secret Sp and sends the combined DH public key Yp=sp·G+YV to
.
Since the server
runs the standard TLS,
will compute a DH secret as Z=sS·Yp
(and ) computes its share of Z as Zp=sp·YS (and ZV=sV·YS). Note that Z=Zp+ZV where + is the group operation of EC(
p). Assuming the discrete logarithm problem is hard in the chosen group, Z is unknown to either party.
Step 2: key derivation. Now that
and
have established additive shares of Z (in the form of EC points), they proceed to derive session keys by evaluating the TLS-PRF keyed with the x coordinate of Z.
A technical challenge here is to harmonize arithmetic operations (i.e., addition in EC (p)) with bitwise operations (i.e., TLS-PRF) in 2PC. It is well-known that boolean circuits are not well-suited for arithmetic in large fields. As a concrete estimate, an EC Point addition resulting in just the x coordinate involves 4 subtractions, one modular inversion, and 2 modular multiplications. An estimate of the AND complexity based on highly optimized circuits results in over 900,000 AND gates just for the subtractions, multiplications, and modular reductions—not even including inversion, which would require running the Extended Euclidean algorithm inside a circuit.
Due to the prohibitive cost of adding EC points in a boolean circuit,
and
convert the additive shares of an EC point in EC (p) to additive shares of its x-coordinate in
p, using the ECtF protocol shown in
p, which can be done with only ˜3||p| AND gates, that is ˜768 AND gates in our implementation where p is 256-bit.
Share conversion using ECtF. The ECtF protocol converts shares in EC (p) to shares in
p. The inputs to the ECtF protocol are two EC points P1, P2ϵEC(
p), denoted Pi=(xiyi). Suppose (xs, ys)=P1*P2 where * is the EC group operation, the output of the protocol is α, βϵ
p such that α+β=xs. Specifically, for the curve we consider, xs-λ2-x1-x2 where λ=(y2-y1)/(x2-x1). Shares of the ys can be computed similarly but we omit that since TLS only uses the xs.
ECtF uses a Multiplicative-to-Additive (MtA) share-conversion protocol as a building block. We use α, β:=MtA (α, β) to denote a run of MtA between Alice and Bob with inputs α and b respectively. At the end of the run, Alice and Bob receive α and β such that a·b=α+β. The protocol can be generalized to handle vector inputs without increasing the communication complexity. Namely for vectors a, b ϵpn, if α, β:=MtA (a, b), then (a, b)=α+β.
Now we describe the protocol of ECtF. ECtF has two main ingredients. Let [α] denote a 2-out-of-2 sharing of a, i.e., [a]=(a1, a2) such that party i has ai for i ϵ{1,2} while a=a1+a2. The first ingredient is share inversion: given [a], compute [a−1]. This can be done as follows: party i samples a random value ri and executes MtA to compute δ1, δ2:=MtA((a1, r1), (r2, a2)). Note that δ1+δ2=a1·r2+a2·r1. Party i publishes vi=δi·ri and thus both parties learn v=v1+v2. Finally, party i outputs βi=ri·v−1. The protocol computes a correct sharing of a−1 because β1+β2=a−1. Moreover, the protocol doesn't leak a to any party assuming MtA is secure. In fact, party i's view consists of (a1+a2) (r1+r1), which is uniformly random since ri is uniformly random.
The second ingredient is share multiplication: compute [ab] given [a], [b]·[ab] can be computed using MtA as follows: parties execute MtA to compute a1, a2 such that a1+a2=a1·b2+a2·b2. Then, party i outputs mi=ai+ai·yi. The security and correctness of the protocol can be argued similarly as above.
Secure evaluation of the TLS-PRF. Having computed shares of the x-coordinate of Z, the so called premaster secret in TLS, in ECtF,
and
evaluate the TLS-PRF in 2PC to derive session keys. Using a known SHA-256 circuit, we hand-optimized the TLS handshake circuit resulting in a circuit with total AND complexity of 779,213.
Adapting 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 TLS 1.2 is straightforward. The first step would remain identical, while output of the second step needs to be truncated, as GCM keys are shorter.
Adapting to TLS 1.3. To support TLS 1.3, the 3P-HS protocol must be adapted to a new handshake flow and a different key derivation circuit. Notably, all handshake messages after the ServerHello are now encrypted. A naïve strategy would be to decrypt them in 2PC, which would be costly as certificates are usually large. However, thanks to the key independence property of TLS 1.3, we can construct a 3P-HS protocol of similar complexity to that for TLS 1.2, as described elsewhere herein.
After the handshake, the prover
sends her query
to the server
as a standard TLS client, but with help from the verifier . Specifically, since session keys are secret-shared, the two parties need to interact and execute a 2PC protocol to construct TLS records encrypting
. Although generic 2PC would in theory suffice, it would be expensive for large queries. We instead introduce custom 2PC protocols that are orders-of-magnitude more efficient.
We first focus on one-round sessions where
sends all queries to
before receiving any response. Most applications of DECO, e.g., proving provenance of content retrieved via HTTP GET, are one-round. Extending DECO to support multi-round sessions is described elsewhere herein.
CBC-HMAC. Recall that
and
hold shares of the MAC key, while
holds the encryption key. To construct TLS records encrypting —potentially private to
, the two parties first run a 2PC protocol to compute the HMAC tag τ of
, and then
encrypts ∥τ locally and sends the ciphertext to
.
Let H denote SHA-256. Recall that the HMAC of message m with key k is
The terms ipad and opad denote respective “inner” and “outer” values utilized in the HMAC algorithm. A direct 2PC implementation would be expensive for large queries, as it requires hashing the entire query in 2PC to compute the inner hash. This is advantageously avoided in illustrative embodiments by making the computation of the inner hash local to
(i.e., without 2PC). If
knew k⊕ ipad, she could compute the inner hash. We cannot, though, simply give k⊕ ipad to P, as she could then learn k and forge MACs.
Our optimization exploits the Merkle-Damgård structure in SHA-256. Suppose m1 and m2 are two correctly sized blocks. Then H (m1∥m2) is computed as fH(fH(IV, m1), m2) where fH denotes the one-way compression function of H, and IV the initial vector.
After the three-party handshake,
and
execute a simple 2PC protocol to compute s0=fH(IV, kMAC⊕ipad), and reveal it to . To compute the inner hash of a message m,
just uses s0 as the IV to compute a hash of m. Revealing s0 does not reveal kMAC, as fH is assumed to be one-way. To compute HMAC (k, m) then involves computing the outer hash in 2PC on the inner hash, a much shorter message. Thus, we manage to reduce the amount of 2PC computation to a few blocks regardless of query length, as opposed to up to 256 SHA-2 blocks in each record with generic 2PC.
AES-GCM. For GCM,
and
perform authenticated encryption of . 2PC-AES is straightforward with optimized circuits, but computing tags for large queries is expensive as it involves evaluating long polynomials in a large field for each record. Our optimized protocol makes polynomial evaluation local via precomputation, as described in more detail elsewhere herein. Since 2PC-GCM involves not only tag creation but also AES encryption, it incurs higher computational cost and latency than CBC-HMAC.
Other embodiments disclosed herein utilize a highly efficient alternative protocol, referred to as a proxy mode protocol, that avoids post-handshake 2PC protocols altogether, with additional trust assumptions.
As illustrated in the full DECO protocol shown in
commits to the session by sending the ciphertexts to , and receives
's MAC key share. Then
can verify the integrity of the response, and prove statements about it.
For clarity, we abstract away the details of zero-knowledge proofs in an ideal functionality ZK. On receiving (“prove”, x, w) from
, where x and w are private and public witnesses respectively,
ZK sends w and the relationship π(x, w)ϵ{0,1} (defined below) to
. Specifically, for CBC-HMAC, x, w, π are defined as follows: x=(kEnc, θs
, R) and w=(
{circumflex over (R)}, kMAC, b). The relationship π(x, w) outputs 1 if and only if (1)
(and {circumflex over (R)}) is the CBC-HMAC ciphertext of
(and R) under key kEnc, kMAC; (2) Query (θs)=
; and (3) Stmt(R)=b. Otherwise it outputs 0.
Assuming functionalities for secure 2PC and ZKPs, it can be shown that ProtDECO as illustrated in Oracle of
More particularly, assuming the discrete log problem is hard in the group used in the three-party handshake, and that f (the compression function of SHA-256) is a random oracle, ProtDECO UC-securely realizes Oracle in the (
2PC,
ZK)-hybrid world, against a static malicious adversary with abort.
The protocol for GCM has a similar flow. The GCM variants of the three-party handshake and query construction protocols were described above.
Unlike CBC-HMAC, GCM is not committing: for a given ciphertext
encrypted with key k, one knowing k can efficiently find k′≠k that decrypts
to a different plaintext while passing the integrity check. To prevent such attacks, we require
to commit to her key share kp before learning s key share. In the proof generation phase, in addition to proving statements about
and R,
needs to prove that the session keys used to decrypt
and {circumflex over (R)} are valid against the commitment to . Proof of the security of the GCM variant is like that for CBC-HMAC.
Recall that the prover
commits to the ciphertext {circumflex over (M)} of a TLS session and proves to
that the plaintext M satisfies certain properties. Without loss of generality, we assume {circumflex over (M)} and M contain only one TLS record, and henceforth call them the ciphertext record and the plaintext record. Multi-record sessions can be handled by repeating the protocol for each record.
Proving only the provenance of M is easy: just reveal the encryption keys. But this sacrifices privacy. Alternatively,
could prove any statement about M using general zero-knowledge techniques. But such proofs are often expensive.
In the following description, we present two classes of statements optimized for example applications: revealing only a substring of the response while proving its provenance (“selective opening”), or further proving that the revealed substring appears in a context expected by
(“context integrity by two-stage parsing”)
Selective Opening. Illustrative embodiments implement what is referred to herein as “selective opening,” techniques that allow
to efficiently reveal or redact substrings in the plaintext. Suppose the plaintext record is composed of chunks M=(B1, . . . , Bn) (details of chunking are discussed below). Selective opening allows
to prove that the ith chunk of M is Bi, without revealing the rest of M; we refer to this as Reveal mode. It can also prove that M−i is the same as M but with the chunks removed. We call this Redact mode. Both modes are simple, but useful for practical privacy goals. The granularity of selective opening depends on the cipher suite, which we now discuss.
CBC-HMAC. Recall that for proof generation,
holds both the encryption and MAC keys kEnc and kMAC, while
only has the MAC key kMAC. Our performance analysis assumes a cipher suite with SHA-256 and AES-128, which matches our implementation, but the techniques are applicable to other parameters. Recall that MAC-then-encrypt is used: a plaintext record M contains up to 1024 AES blocks of data and 3 blocks of MAC tag σ, which we denote as M=(B1, . . . . B1024,σ) where σ=(B1025, B1026, B1027). {circumflex over (M)} is a CBC encryption of M, consisting of the same number of blocks: {circumflex over (M)}=({circumflex over (B)}1, . . . , {circumflex over (B)}1024, {circumflex over (σ)}) where {circumflex over (σ)}=({circumflex over (B)}1025, {circumflex over (B)}1026, {circumflex over (B)}1027).
Revealing a TLS record. A naïve way to prove that {circumflex over (M)} encrypts M without revealing kEnc is to prove correct encryption of each AES block in ZKP. However, this would require up to 1027 invocations of AES in ZKP, resulting in impractical performance.
Leveraging the MAC-then-encrypt structure, the same can be done using only 3 invocations of AES in ZKP. This illustratively involves proving that the last few blocks of {circumflex over (M)} encrypt a tag σ and revealing the plaintext directly. Specifically,
computes
and sends (M, π) to . Then
verifies π and checks the MAC tag over M (note that
knows the MAC key.) Its security relies on the collision-resistance of the underlying hash function in HMAC, i.e.,
cannot find M′≠M with the same tag σ.
Revealing a record with redacted blocks. Suppose the ith block contains sensitive information that
wants to redact. A direct strategy is to prove that Bi−=(B1, . . . , Bi−1) and Bi+=(Bi+1, . . . , Bn) form the prefix and suffix of the plaintext encrypted by {circumflex over (M)}, by computing
This is expensive though as it would involve 3 AES and 256 SHA-256 compression in ZKP.
Leveraging the Merkle-Damgård structure of SHA-256, several optimizations are possible. Let f denote the compression function of SHA-256, and Si−1 the state after applying f on Bi−. First, if both Si−1 and si can be revealed, e.g., when Bi contains high-entropy data such as API keys, the above goal can be achieved using just 1 SHA-256 in ZKP. To do so,
computes π=ZK-PoK{Bi: f(si−1, Bi)=si} and sends (π·si−1si−1, si, Bi−, Bi+) to , who then 1) checks si−1 by recomputing it from Bi−; 2) verifies π; and 3) checks the MAC tag o by recomputing it from si and Bi+. Assuming Bi is high entropy, revealing si−1 and si doesn't leak Bi since f is one-way.
On the other hand, if both si−1 and si cannot be revealed to
(e.g., when brute-force attacks against Bi is feasible), we can still reduce the cost by having
redact a prefix (or suffix) of the record containing the block Bi. The cost incurred then is 256-i SHA-2 hashes in ZKP. Additional details are provided elsewhere herein. Generally ZKP cost is proportional to record sizes so TLS fragmentation can also lower the cost by a constant factor.
Redacting a suffix. When a suffix Bi+ is to be redacted,
computes π=ZK-PoK {Bi+, KEnc: f(si, Bi+)=ih ∧H(kMAC⊕ opad∥ih)=σ∧B1025∥B1026∥B1027=CBC(kEnc, σ)} and si is the state after applying f on Bi−∥Bi·
sends (π, Bi−∥Bi) to . The verifier then 1) checks si−1 by applying f on Bi−∥Bi, and 2) verifies π. Essentially, the security of this follows from pre-image resistance of f. Moreover,
doesn't learn the redacted suffix since ih=f(s, Bi+) is kept secret from . The total cost is 3 AES and 256-i SHA-2 hashes in ZKP.
Redacting a prefix.
computes two ZKPs: 1) π1=ZK-POK{B1−, kMAC: H(kMAC⊕ ipad∥Bi−)=Si−1}: 2) π2=ZK-POK{kMAC, kEnc:H(kMAC⊕opad∥ih)=π∧B1025∥B1026∥B1027=CBC(kEnc, π)}.
sends (π1, π2, si−1, Bi∥Bi+) to . The verifier checks that 1) si−1 is correct using π1 and then computes f (si−1, Bi∥Bi+) to obtain the inner hash ih, 2)π2 is verified using the computed ih. The cost incurred is 3 AES and 256-i SHA-2 hashes in ZKP.
Note that redacting a prefix/suffix only makes sense if the revealed portion does not contain any private user data. Otherwise,
would have to find the smallest substring containing all the sensitive blocks and redact either the prefix/suffix similar to above.
GCM. Unlike CBC-HMAC, revealing a block is very efficient in GCM. First,
reveals AES (k, IV) and AES (k, 0), with proofs of correctness in ZK, to allow
to verify the integrity of the ciphertext. Then, to reveal the ith block,
just reveals the encryption of the ith counter Ci=AES (k, inci(IV) with a correctness proof. V can decrypt the ith block as {circumflex over (B)}i⊕Ci. IV is the public initial vector for the session, and inci (IV) denotes incrementing IV for i times (the exact format of inc is immaterial.) To reveal a TLS record,
repeat the above protocol for each block. Again, additional details are provided elsewhere herein.
In summary, CBC-HMAC allows efficient selective revealing at the TLS record-level and redaction at block level in DECO, while GCM allows efficient revealing at block level. Selective opening can also serve as pre-processing to reduce the input length for a subsequent zero-knowledge proof.
Context Integrity by Two-Stage Parsing. For many applications, the verifier
may need to verify that the revealed substring appears in the right context. We refer to this property as “context integrity.” In the following we present techniques for
to specify contexts and for
to prove context integrity efficiently.
For ease of exposition, our description below initially focuses on the revealing mode, i.e.,
reveals a substring of the server's response to . The redaction mode will then be described.
Specification of contexts. Our techniques for specifying contexts assume that the TLS-protected data sent to and from a given server
has a well-defined context-free grammar , known to both
and . In a slight abuse of notation, we let
denote both a grammar and the language it specifies. Thus, R ϵ
denotes a string R in the language given by . We assume that
is unambiguous, i.e., every Rϵ
has a unique associated parse-tree TR. JSON and HTML are examples of two widely used languages that satisfy these requirements, and are our focus here.
When
then presents a substring Ropen of some response R from , we say that Ropen has context integrity if Ropen is produced in a certain way expected by
. Specifically,
specifies a set S of positions in which she might expect to see a valid substring Ropen in R. In our definition, S is a set of paths from the root in a parse-tree defined by
to internal nodes. Thus s ϵS, which we call a permissible path, is a sequence of non-terminals. Let pR denote the root of TR (the parse-tree of R in ). We say that a string Ropen has context-integrity with respect to (R, S) if TR has a subtree whose leaves yield (i.e. concatenate to form) the string Ropen, and that there is a path s ϵS from pR to the root of the said subtree.
Formally, we define context integrity in terms of a predicate . More particularly, given a grammar
on TLS responses, R ϵ, a substring Ropen of R, a set S of permissible paths, we define a context function
as a boolean function such that : (S, R, Ropen)
true if and only if there exists a sub-tree TR
(S, R, Ropen)=true.
Referring again to the example of
Start→object object→{pairs}
pair→“key”:value pairs→|pair, pairs
key→chars value→chars|object
In that example,
was interested in learning the derivation of the pair ρbalance with key “balance” in the object given by the value of the pair ρchecking with key “checking a/c”. Each of these non-terminals is the label for a node in the parse-tree TJ. The path from the root Start of TJ to ρchecking requires traversing a sequence of nodes of the form Start→object→pairs*→ρchecking, where pairs* denotes a sequence of zero or more pairs. So S is the set of such sequences and Ropen is the string “checking a/c”: {“balance”: $2000}.
Two-stage parsing. Generally, proving Ropen has context integrity, i.e.,
(S, R, Ropen)=true, without directly revealing R would be expensive, since computing
may require computing TR for a potentially long string R. However, we observed that under certain assumptions that TLS-protected data generally satisfies, much of the overhead can be removed by having
preprocess R by applying a transformation Trans agreed upon by
and , and prove that Ropen has context integrity with respect to R′ (a usually much shorter string) and S′ (a set of permissible paths specified by
based on S and Trans).
Based on this observation, we introduce a two-stage parsing scheme for efficiently computing Ropen and proving
(S, R, Ropen)=true. Suppose
and
agree upon , the grammar used by the web server, and a transformation Trans. Let
′ be the grammar of strings Trans (R) for all R ϵ
. Based on Trans,
specifies permissible paths S′ and a constraint-checking function . In the first stage,
: (1) computes a substring Ropen of R by parsing R (such that
(S, R, Ropen)=true) (2) computes another string R′=Trans (R). In the second stage,
proves to
in zero-knowledge that (1) , (R, R′)=true and (2)
, (S′, R′, Ropen)=true. Note that in addition to public parameters
,
′, S, S′, Trans,
, the verifier only sees a commitment to R, and finally, Ropen.
This protocol makes the zero-knowledge computation significantly less expensive by deferring actual parsing to a non-verifiable computation. In other words, the computation of , (S′, R′, Ropen) and
, (R, R′) can be much more efficient than that of
(S, R, Ropen).
We formalize the correctness condition for the two-stage parsing in an operational semantics rule given below. Here, f, σ
denotes applying a function f on input σ, while
denotes that if the premise P is true, then the conclusion C is true.
Given a grammar , a context function and permissible paths
(S, ·,·), a transformation Trans, a grammar
′={R′: R′=Trans(R), R ϵ
} with context function and permissible paths
, (S′,·,·) and a function
, we say (
, S′) are correct with respect to S, if for all (R, R′, Ropen) such that R ϵ
, booleans b the following rule holds:
Below, we focus on an example grammar suitable for use in DECO applications, and present concrete constructions of two-stage parsing schemes.
Key-value grammars. A broad class of data formats, such as JSON, have a notion of key-value pairs. Thus, they are our focus in some embodiments of DECO.
A key-value grammar G produces key-value pairs according to the rule, “pair->start key middle value end”, where start, middle and end are delimitors. For such grammars, an array of optimizations can greatly reduce the complexity for proving context. We discuss a few such optimizations below, with other details provided elsewhere herein.
Revelation for a globally unique key. For a key-value grammar , set of paths S, if for an R ϵ
, a substring Ropen satisfying context-integrity requires that Ropen is parsed as a key-value pair with a globally unique key K, Ropen simply needs to be a substring of R and correctly be parsed as a pair. Specifically, Trans(R) outputs a substring R′ of R containing the desired key, i.e., a substring of the form “start K middle value end” and
can output Ropen=R′. ′ can be defined by the rule
,→pair where
, is the start symbol in the production rules for
′. Then (1)
, (R, R′) checks that R′ is a substring of R and (2) for S′={
,}, C
,
, (S′, R′, Ropen) checks that (a) R′ ϵ
′ and (b) Ropen=R′. Globally unique keys arise in some applications herein, such as when selectively opening the response for age.
Redaction in key-value grammars. Thus far, our description of two-stage parsing assumes the Reveal mode in which
reveals a substring Ropen of R to
and proves that Ropen has context integrity with respect to the set of permissible paths specified by . In the Redact mode, the process is similar, but instead of revealing Ropen in the clear,
generates a commitment to Ropen using techniques described previously and reveals R, with Ropen removed, for example, by replacing its position with a dummy character.
DECO as disclosed herein can be used for any oracle-based application. To illustrate its versatility, we have implemented and evaluated three example applications that leverage its various capabilities: 1) a confidential financial instrument realized by smart contracts; 2) converting legacy credentials to anonymous credentials; and 3) privacy-preserving price discrimination reporting.
Confidential Financial Instruments. Financial derivatives are among the most commonly cited smart contract applications, and exemplify the need for authenticated data feeds (e.g., stock prices). For example, one popular financial instrument that is easy to implement in a smart contract is a binary option. This is a contract between two parties betting on whether, at a designated future time, e.g., the close of day D, the price P* of some asset N will equal or exceed a predetermined target price P, i.e., P*≥P. A smart contract implementing this binary option can call an oracle
to determine the outcome.
In principle,
can conceal the underlying asset N and target price P for a binary option on chain. It simply accepts the option details off chain, and reports only a bit specifying the outcome Stmt:=P*≥?P. This approach is referred to as a Mixicle.
A limitation of a basic Mixicle construction is that
itself learns the details of the financial instrument. Prior to DECO, only oracle services that use trusted execution environments (TEEs) could conceal queries from . We now show how DECO can support execution of the binary option without
learning the details of the financial instrument, i.e., N or P. It should be noted in this regard that the predicate direction ≥? or ≤? can be randomized. Also, winner and loser identities and payment amounts can be concealed. Additional steps can be taken to conceal other metadata, e.g., the exact settlement time.
In this example application, the option winner plays the role of , and obtains a signed result of Stmt from
, which plays the role of
. We now describe the protocol and its implementation. Let {
,
} denote the oracle's key pair. In this embodiment, a binary option is specified by an asset name N, threshold price P, and settlement date D. We denote the commitment of a message M by CM=com(M, rM) with a witness rM.
she has won. Examples of request and response are shown to the right, and shaded text in this portion of the figure is sensitive information to be redacted.
The binary option process illustrated in
Upon successful proof verification, the oracle returns a signed statement with the contract ID, S=Sig(,
).
Alice and Bob need to trust
for integrity, but not for privacy. They can further hedge against integrity failure by using multiple oracles, as explained elsewhere herein. Decentralizing trust over oracles is a standard and already deployed technique. We emphasize that DECO ensures privacy even if all the oracles are malicious.
As indicated above, ) also needs to reveal enough portion of the HTTP GET request to oracle (
) in order to convince access to the correct API endpoint. The GET request contains several parameters—some to be revealed like the API endpoint, and others with sensitive details like stock name and private API key.
redacts sensitive params using techniques disclosed herein and reveals the rest to . The API key provides enough entropy preventing
from learning the sensitive params. Without additional care though, a cheating
can alter the semantics of the GET request and conceal the cheating by redacting extra parameters. To ensure this does not happen,
needs to prove that the delimiter “&” and separator “=” do not appear in the redacted text.
Let {circumflex over (R)} and R denote the response ciphertext and the plaintext respectively. To settle an option,
proves to
that R contains evidence that he won the option, using the two-stage parsing scheme described previously. In the first stage,
parses R locally and identifies the smallest substring of R that can convince . In the
proves knowledge of (Rprice, P, rp) in ZK such that 1) Rprice is a substring of the decryption of {circumflex over (R)}; 2) Rprice starts with “05. price”; 3) the subsequent characters form a floating point number P* and that P*≥P; and 4) com (P, rp)=Cp.
This two-stage parsing is secure assuming the keys are unique and the key “05. price” is followed by the price, making the grammar of this response a key-value grammar with unique keys, as described above. Similarly,
proves that the stock name and date contained in R match the commitments. With the CBC-HMAC cipher suite, the zero-knowledge proof circuit involves redacting an entire record (408 bytes), computing commitments, and string processing.
HTTP GET requests (and HTML) have a special restriction: the demarcation between a key and a value (i.e., middle) and the start of a key-value pair (i.e., start) are never substrings of a key or a value. This means that to redact more than a single contiguous key or value,
must redact characters in {middle, start}. So we have , (R, R′) check that: (1) |R|=|R′|; and (2) ∀iϵ|R′l|, either R′[i]=D∧R[i]∉{middle, start} or R[i]=R′[i] (D is a dummy character used to do in-place redaction). Checking
is then unnecessary.
Legacy Credentials to Anonymous Credentials: Age Proof. User credentials are often inaccessible outside a service provider's environment. Some providers offer third-party API access via OAuth tokens, but such tokens reveal user identifiers. DECO allows users holding credentials in existing systems (what we call “legacy credentials”) to prove statements about them to third parties (verifiers) anonymously. Thus, DECO in some embodiments allows users to convert any web-based legacy credential into an anonymous credential without server-side support or trusted hardware.
In the
Price Discrimination. Price discrimination refers to selling the same product or service at different prices to different buyers. Ubiquitous consumer tracking enables online shopping and booking websites to employ sophisticated price discrimination, e.g., adjusting prices based on customer zip codes. Price discrimination can lead to economic efficiency, and is thus widely permissible under existing laws.
In the U.S., however, the FTC forbids price discrimination if it results in competitive injury, while new privacy-focused laws in Europe, such as the GDPR, are bringing renewed focus to the legality of the practice. Consumers in any case generally dislike being subjected to price discrimination. Currently, however, there is no trustworthy way for users to report online price discrimination.
As illustrated in
We now describe implementation details and evaluation results for DECO and the three applications.
Three-Party Handshake and Query Execution. We implemented the three-party handshake protocol (3P-HS) for TLS 1.2 and query execution protocols (2PC-HMAC and 2PC-GCM) in about 4700 lines of C++ code. We built a hand-optimized TLS-PRF circuit with total AND complexity of 779,213. We also used variants of a known AES circuit. Our implementation uses Relic for the Paillier cryptosystem and the EMP toolkit for the maliciously secure 2PC protocol.
We integrated the three-party handshake and 2PC-HMAC protocols with mbedTLS, a popular TLS implementation, to build an end-to-end system. 2PC-GCM can be integrated to TLS similarly with more engineering effort. We evaluated the performance of 2PC-GCM separately. The performance impact of integration should be negligible. We did not implement 3P-HS for TLS 1.3, but it is believed that the performance should be comparable to that for TLS 1.2, since the circuit complexity is similar.
We evaluated the performance of DECO in both the LAN and WAN settings. Both the prover and verifier run on a c5.2xlarge Amazon Web Services (AWS) node with 8 virtual Central Processing Unit (vCPU) cores and 16 gigabytes (GB) of random access memory (RAM). We located the two nodes in the same region (but different availability zones) for the LAN setting, but in two distinct data centers (in Ohio and Oregon) in the WAN setting. The round-trip time between two nodes in the LAN and WAN is about 1 ms and 67 ms, respectively, and the bandwidth is about 1 Gbps.
TABLE 1 below summarizes the runtime of DECO protocols during a TLS session. 50 samples were used to compute the mean and standard error of the mean (in parenthesis). The MPC protocol we used relies on offline preprocessing to improve performance. Since the offline phase is input- and target-independent, it can be done prior to the TLS session. Only the online phase is on the critical path.
As shown in TABLE 1, DECO protocols are very efficient in the LAN setting. It takes 0.37 seconds to finish the three-party handshake. For query execution, 2PC-HMAC is efficient (0.13s per record) as 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, as it involves 2PC-AES over the entire query. We evaluated its performance with queries ranging from 256B to 2 KB, the typical sizes seen in HTTP GET requests. In the LAN setting, the performance is efficient and comparable to 2PC-HMAC.
In the WAN setting, the runtime is dominated by the network latency because MPC involves many rounds of communication. Nonetheless, the performance is still acceptable, given that DECO is likely to see only periodic use for most applications we consider.
Proof Generation. We instantiated zero-knowledge proofs with a standard proof system in libsnark. We have devised efficiently provable statement templates, but users of DECO need to adapt them to their specific applications. Succinct non-interactive argument of knowledge (SNARK) compilers enable such adaptation in a high-level language, concealing low-level details from developers. We used xjsnark and its Java-like high-level language to build statement templates and libsnark compatible circuits.
Our rationale in choosing libsnark is its relatively mature tooling support. The proofs generated by libsnark are constant-size and very efficient to verify, the downside being the per-circuit trusted setup. With more effort, DECO can be adapted to use, e.g., Bulletproofs, which requires no trusted setup but has large proofs and verification time.
We measure five performance metrics for each example-prover time (the time to generate the proofs), verifier time (the time to verify proofs), proof size, number of arithmetic constraints in the circuit, and the peak memory usage during proof generation.
TABLE 2 below summarizes the results. 50 samples were used to compute the mean and its standard error. Through the use of efficient statement templates and two-stage parsing, DECO achieves very practical prover performance. Since libsnark optimizes for low verification overhead, the verifier time is negligible. The number of constraints (and prover time) is highest for the binary option application due to the extra string parsing routines. We use multiple proofs in each application to reduce peak memory usage. For the most complex application, the memory usage is 1.78 gigabytes (GB). As libsnark proofs are of a constant size 287 bytes (B), the proof sizes shown are multiples of that.
End-to-End Performance. DECO end-to-end performance depends on the available TLS cipher suites, the size of private data, and the complexity of application-specific proofs. Here we present the end-to-end performance of the most complex application of the three we implemented-the binary option. It takes about 13.77s to finish the protocol, which includes the time taken to generate unforgeable commitments (0.50s), to run the first stage of two-stage parsing (0.30s), and to generate zero-knowledge proofs (12.97s). These numbers are computed in the LAN setting; in the WAN setting, MPC protocols are more time-consuming (5.37s), pushing the end-to-end time up to 18.64s.
In comparison, Town Crier uses TEEs to execute a similar application in about 0.6s, i.e., around 20× faster than DECO, but with added trust assumptions. Since DECO is likely to be used only periodically for most applications, its overhead in achieving cryptographic-strength security assurances seems reasonable.
Although users can already retrieve their data from websites, DECO allows users to export the data with integrity proofs without their explicit approval or even awareness. We now briefly discuss the resulting legal and compliance considerations.
Critically, however, DECO users cannot unilaterally export data to a third party with integrity assurance, but rely on oracles as verifiers for this purpose. While DECO keeps user data private, oracles learn what websites and types of data a user accesses. Thus oracles can enforce appropriate data use, e.g., denying transactions that may result in copyright infringement.
Both users and oracles bear legal responsibility for the data they access. Recent case law on the Computer Fraud and Abuse Act (CFAA), however, shows a shift away from criminalization of web scraping, and federal courts have ruled that violating websites' terms of service is not a criminal act per se. Users and oracles that violate website terms of service, e.g., “click wrap” terms, instead risk civil penalties. DECO compliance with a given site's terms of service is a site-and application-specific question.
Oracles have an incentive to establish themselves as trustworthy within smart-contract and other ecosystems. We expect that reputable oracles will provide users with menus of the particular attestations they issue and the target websites they permit, vetting these options to maximize security and minimize liability and perhaps informing or cooperating with target servers.
The legal, performance, and compliance implications of incorrect attestations based on incorrect (and potentially subverted) data are also important. Internet services today have complex, multi-site data dependencies, though, so these issues aren't specific to DECO. Oracle services already rely on multiple data sources to help ensure correctness. Oracle services in general could ultimately spawn infrastructure like that for certificates, including online checking and revocation capabilities and different tiers of security.
DECO in illustrative embodiments disclosed herein is a privacy-preserving, decentralized oracle scheme for modern TLS versions that requires no trusted hardware or server-side modifications. DECO allows a prover to generate unforgeable commitments to TLS sessions and efficiently prove statements about session content. Some embodiments mitigate context-integrity attacks that are universal to privacy-preserving oracles, utilizing a novel two-stage parsing scheme. DECO can liberate data from centralized web-service silos, making it accessible to a rich spectrum of applications. The practicality of DECO is demonstrated herein through a fully functional implementation along with three example applications.
GCM is an authenticated encryption with additional data (AEAD) cipher. To encrypt, the GCM cipher takes as inputs a tuple (k, IV, M, A): a secret key, an initial vector, a plaintext of multiple AES blocks, and additional data to be included in the integrity protection; it outputs a ciphertext C and a tag T. Decryption reverses the process. The decryption cipher takes as input (k, IV, C, A, T) and first checks the integrity of the ciphertext by comparing a recomputed tag with T, then outputs the plaintext.
The ciphertext is computed in the counter mode: Ci=AES (k, inci(IV)) ⊕Mi where inci denotes incrementing IV for i times (the exact format of inc is immaterial.)
The tag Tag(k, IV, C, A) is computed as follows. Given a vector X ϵ2m128, the associated GHASH polynomial PX:
2128→
2128 is defined as PX(h)=Σi=1mXi·hm−i+1 with addition and multiplication done in
2128. Without loss of generality, suppose A and C are properly padded. Let
A and
C denote their length. A GCM tag is
When GCM is used in TLS, each plaintext record D is encrypted as follows. A unique nonce n is chosen and the additional data k is computed as a concatenation of the sequence number, version, and length of D. GCM encryption is invoked to generate the payload record as M=n∥GCM(k, n, D, K).
Additional details regarding GCM can be found in, for example, Morris J Dworkin, SP 800-38d, “Recommendation for block cipher modes of operation: Galois/counter mode (GCM) and GMAC,” Technical Report, 2007, which is incorporated by reference herein.
Tag creation/verification. Computing or verifying a GCM tag involves evaluating Equation (1) above in 2PC. A challenge is that Equation (1) involves both arithmetic computation (e.g., polynomial evaluation in 2128) as well as binary computation (e.g., AES). Performing multiplication in a large field in a binary circuit is expensive, while computing AES (defined in GF(28)) in
2128 incurs high overhead. Even if the computation could somehow be separated into two circuits, evaluating the polynomial alone—which takes approximately 1,000 multiplications in
2128 for each record—would be unduly expensive.
Our protocol removes the need for polynomial evaluation. The actual 2PC protocol involves only binary operations and thus can be done in a single circuit. Moreover, the per-record computation is reduced to only one invocation of 2PC-AES.
This is achieved by computing shares of {hi} (in a 2PC protocol) in a preprocessing phase at the beginning of a session. The overhead of preprocessing is amortized over the session because the same h used for all records that follow. With shares of {hi},
and
can compute shares of a polynomial evaluation
(h) locally. They also compute AES (k, IV) in 2PC to get a share of Tag (k, IV, C, A). In total, only one invocation of 2PC-AES in needed to check the tag for each record.
It is critical that
never responds to the same IV more than once; otherwise
would learn h. Specifically, in each response,
reveals a blinded linear combination of her shares {} in the form of
V,X=AES(k, IV) ⊕ΣiXi·
. It is important that the value is blinded by AES (k, IV) because a single unblinded linear combination of {
} would allow
to solve for h. Therefore, if
responds to the same IV twice, the blinding can be removed by adding the two responses (in 2128):
IV,X ⊕
V,X′=Σi(Xi+X′1)·
. This follows from the nonce uniqueness requirement of GCM.
Encrypting/decrypting records. Once tags are properly checked, decryption of records is straightforward.
and
simply compute AES encryption of inc′ (IV) with 2PC-AES. A subtlety to note is that
must check that the counters to be encrypted have not been used as IV previously. Otherwise
would learn h to
in a manner like that outlined above.
wants to convince
that an AES block Bi is the ith block in the encrypted record rêc. The proof strategy is as follows: 1) prove that AES block Bi encrypts to the ciphertext block {circumflex over (B)}i and 2) prove that the tag is correct. Proving the correct encryption requires only 1 AES in ZKP. Naïvely done, proving the correct tag incurs evaluating the GHASH polynomial of degree 512 and 2 AES block encryptions in ZKP.
We manage to achieve a much more efficient proof by allowing
to reveal two encrypted messages AES (k, IV) and AES (k, 0) to , thus allowing
to verify the tag (see Equation (1)).
only needs to prove the correctness of encryption in ZK and that the key used corresponds to the commitment, requiring 2 AES and 1 SHA-2 (
commits to kp by revealing a hash of the key). Thus, the total cost is 3 AES and 1 SHA-2 in ZKP.
Revealing a TLS record. The proof techniques are a simple extension from the above case.
reveals the entire record rec and proves correct AES encryption of all the AES blocks, resulting in a total 514 AES and 1 SHA-2 in ZKP.
Revealing a TLS record except for a block. Similar to the above case,
proves encryption of all the blocks in the record except one, resulting in a total 513 AES and 1 SHA-2 in ZKP.
Adapting to Support TLS 1.3. To support TLS 1.3, the 3P-HS protocol must be adapted to a new handshake flow and a different key derivation circuit. Notably, all handshake messages after the ServerHello are now encrypted. A naïve strategy would be to decrypt them in 2PC, which would be costly as certificates are usually large. However, thanks to the key independence property of TLS 1.3,
and
can securely reveal the handshake encryption keys without affecting the secrecy of final session keys. Handshake integrity is preserved because the Finished message authenticates the handshake using yet another independent key.
Therefore the optimized 3P-HS work as follows.
and
perform ECDHE the same as before. Then they derive handshake and application keys by executing 2PC-HKDF, and reveal the handshake keys to , allowing
to decrypt handshake messages locally (i.e., without 2PC). The 2PC circuit involves roughly 30 invocations of SHA-256, totaling to approximately 70k AND gates, comparable to that for TLS 1.2. Finally, since CBC-HMAC is not supported by TLS 1.3, DECO can only be used in GCM mode.
Query Construction is Optional. For applications that bind responses to queries, e.g., when a stock ticker is included with the quote, 2PC query construction protocols can be avoided altogether. Since TLS uses separate keys for each direction of communication, client-to-server keys can be revealed to
after the handshake so that
can query the server without interacting with .
Supporting Multi-Round Sessions. DECO can be extended to support multi-round sessions where
sends further queries depending on previous responses. After each round,
executes similar 2PC protocols as above to verify MAC tags of incoming responses, since MAC verification and creation is symmetric. However an additional commitment is required to prevent
from abusing MAC verification to forge tags.
In TLS, different MAC keys are used for server-to-client and client-to-server communication. To support multi-round sessions,
and
run 2PC to verify tags for the former, and create tags on fresh messages for the latter. Previous description herein specified the protocols to create (and verify) MAC tags. Now we discuss additional security considerations for multi-round sessions.
When checking tags for server-to-client messages, we must ensure that
cannot forge tags on messages that are not originally from the server. Suppose
wishes to verify a tag T on message M. We have
first commit to T, then
and
run a 2PC protocol to compute a tag T′ on message M.
is asked to open the commitment to
and if T≠T′,
aborts the protocol. Since
doesn't know the MAC key,
cannot compute and commit to a tag on a message that is not from the server.
When creating tags for client-to-server messages,
makes sure MAC tags are created on messages with increasing sequence numbers, as required by TLS. This also prevents a malicious
from creating two messages with the same sequence number, because there is no way for
to distinguish which one was sent to the server.
An Alternative DECO Protocol: Proxy Mode. As shown in TABLE 1, the HMAC mode of DECO is highly efficient and the runtime of 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 a highly efficient alternative that avoids post-handshake 2PC protocols altogether.
In this alternative, the verifier
acts as a proxy between the prover
and the TLS server , i.e.,
sends/receives messages to/from
through . The modified flow of the DECO protocol is as follows: after the three-party handshake,
commits to her key share
then
reveals
to . Therefore
now has the entire session key k=+
. As
uses k to continue the session with the server,
records the proxy traffic. After the session concludes,
proves statements about the recorded session the same as before.
In such an embodiment, the three-party handshake provides unforgeability. Unlike CBC-HMAC, GCM is not committing: for a given ciphertext and tag (C, T) encrypted with key k, one can find k′≠k that decrypts C to a different plaintext while computing the same tag, as GCM MAC is not collision-resistant. To prevent such attacks, the above protocol requires
to commit to her key share before learning the session key.
Security properties and network assumptions relating to the proxy mode protocol will now be described. The verifier-integrity and privacy properties are clear, as a malicious
cannot break the integrity and privacy of TLS (by assumption).
For prover integrity, though, we need to assume that the proxy can reliably connect to
throughout the session. First, we assume the proxy can ascertain that it indeed is connected with . Moreover, we assume messages sent between the proxy and
cannot be tampered with by , who knows the session keys and thus could modify the session content.
Note that during the three-party handshake,
can ascertain the server's identity by checking the server's signature over a fresh nonce (in standard TLS). After the handshake, however,
has to rely on network-layer indicators, such as IP addresses. In practice,
must therefore have correct, up-to-date DNS records, and that the network between
and the server (e.g., their ISP and the backbone network) must be properly secured against traffic injection, e.g., through Border Gateway Protocol (BGP) attacks. Eavesdropping is generally not problematic in illustrative embodiments.
These assumptions have been embraced by other systems in a similar proxy setting, as BGP attacks are challenging to mount in practice. We can further enhance our protocol against traffic interception by distributing verifier nodes geographically. Moreover, various known detection techniques can be deployed by verifiers. Often BGP attacks are documented after the fact, therefore, when applicable, applications of DECO can be enhanced to support revocation of affected sessions (for example, when DECO is used to issue credentials in an identity system.)
This alternative protocol represents a different performance-security tradeoff. It's highly efficient because no intensive cryptography occurs after the handshake, but it requires additional assumptions about the network and therefore only withstands a weaker network adversary.
Preliminaries and Notation. We denote context-free grammars (CFGs) as =(V, Σ, P, S) where V is a set of non-terminal symbols, Σ a set of terminal symbols, P:V→(V ∪Σ) * a set of productions or rules and S ϵV the start-symbol. We define production rules for CFGs in standard notation using ‘−’ to denote a set minus and ‘ . . . ’ to denote a range. For a string w, a parser determines if w ϵ
by constructing a parse tree for w. The parse tree represents a sequence of production rules which can then be used to extract semantics.
Key-Value Grammars. These are grammars with the notion of key-value pairs. These grammars are particularly interesting for DECO since most API calls and responses are, in fact, key-value grammars.
is said to be a key-value grammar if there exists a grammar , such that given any s ϵ
, s ϵ
, and
can be defined by the following rules:
In the above, S is the start non-terminal (represents a sentence in ), the non-terminals open and close demarcate the opening and closing of the set of key-value pairs and start, middle, end are special strings demarcating the start of a key-value pair, separation between a key and a value and the end of the pair respectively.
In order to remove ambiguity in parsing special characters, i.e., characters which have special meaning in parsing a grammar, a special non-terminal, escape is used. For example, in JSON, keys are parsed when preceded by ‘whitespace double quotes’ (“) and succeeded by double quotes. If a key or value expression itself must contain double quotes, they must be preceded by a backslash (\), i.e., escaped. In the above rules, the non-terminal unescaped before special characters means that they can be parsed as special characters. So, moving forward, we can assume that the production of a key-value pair is unambiguous. So, if a substring R′ of a string R in the key-value grammar
parses as a pair, R′ must correspond to a pair in the parse tree of R.
Note that in the above key-value grammar, middle cannot derive an empty string, i.e., a non-empty string must mark middle to allow parsing keys from values. However, one of start and end can have an empty derivation, since they only demarcate the separation between value in one pair from key in the next. Finally, we note that in the two-stage parsing for key-value grammars in some embodiments, we only we consider permissible paths with the requirement that the selectively opened string, Ropen corresponds to a pair.
Two-Stage Parsing for a Locally Unique Key. Many key-value grammars enforce key uniqueness within a scope. For example, in JSON, it can be assumed that keys are unique within a JSON object, even though there might be duplicated keys across objects. The two-stage parsing for such grammars can be reduced to parsing a substring. Specifically, Trans extracts from R a continuous substring R′, such that the scope of a pair can be correctly determined, even within R′. For instance, in JSON, if , (R, R′) returns true if and only if R′ is a prefix of R, then only parsing R′ as a JSON, up to generating the sub-tree yielding Ropen is sufficient for determining whether a string Ropen corresponds to the correct context in R.
Grammars with Unique Keys. Given a key-value grammar
we define a function which checks for uniqueness of keys, denoted . Given a string s ϵ
and another string k, (s, k)=true if and only if there exists at most one substring of s that can be parsed as start k middle. Since sϵ
, this means, in any parse tree of s, there exists at most one branch with node key and derivation k. Let
be a function that returns true if its input is in the grammar . We say a grammar
is a key-value grammar with unique keys if for all s ϵ
and all possible keys k, (s,k)=true, i.e., for all strings R, C:
Concrete Two-Stage Parsing for Unique-Key Grammars. Let
be a unique-key grammar as given above. We assume that
is LL (1). This is the case for example grammars of interest described previously. General LL (1) parsing algorithms are known.
We instantiate a context function,
for a set T, such that T contains the permissible paths to a pair for strings in . We additionally allow
to take as input an auxiliary restriction, a key k (the specified key in 's output Ropen). The tuple (T, k) is denoted S and
(S,·,·) .
Let
be a grammar given by the rule →pair, where pair is the non-terminal in the production rules for
and
is the start symbol in . We define
as a function that decides whether a string s is in
and if so, whether the key in s equals k. On input R, Ropen,
checks that: (a) Ropen is a valid key-value pair with key k by running (b) Ropen parses as a key-value pair in R by running an LL (1) parsing algorithm to parse R.
to parse a string R in a key-value grammar , and search for the production of a particular key-value pair Ropen. Here, PTable, the LL (1) parse-table for
is hard-coded into .
To avoid expensive computation of
on a long string R, we introduce the transformation Trans, to extract the substring R′ of R, such that R′=Ropen as per the requirements.
For string s, t, we also define functions substring (s, t), that returns true if t is a substring of s and equal (s, t) which returns true if s=t. We define
with the rule:
and S′={}. Meaning,
(S, R′, Ropen=true whenever equal (R′, Ropen) and the rule
holds for all strings R′, Ropen.
It can be shown that (, S′) are correct with respect to S. More particularly, if R′ is substring of R, a key-value pair Ropen is parsed by
then the same pair must have been a substring of . Due to global uniqueness of keys in
, there exists only one such pair Ropen and
(S, R, Ropen) must be true.
The additional protocol details above, like those described elsewhere herein, are presented by way of illustrative example only, and are not intended to be limiting in any way. Other embodiments can utilize alternative protocol arrangements in implementing decentralized oracles as disclosed herein.
As indicated above, illustrative embodiments of decentralized oracles as disclosed herein can be implemented in a wide variety of different applications.
For example, DECO can be used to implement a personal data marketplace, where users control and sell their personal data. It is well known that web services profit from monetizing user data. A personal data marketplace implemented using the techniques disclosed herein can disrupt this data monopoly by enabling users to sell their data in an open marketplace. DECO is a key enabler to a personal data marketplace in illustrative embodiments because DECO enables buyers to verify the origin and integrity of the data from websites. DECO also allows sellers to preprocess the data, e.g., redacting sensitive information, for privacy protection while preventing sellers from cheating. Some implementations utilize DECO to provide verifiable claims against price discrimination.
As another example, DECO can be used to provide proof of financial solvency. As a more particular illustration of an arrangement of this type, with DECO, Alice can prove to Bob that her balance with a particular bank is more than $5000. This simple proof not only shows Alice's financial solvency but also her ability to open an account (e.g., that Alice is not on any sanctions lists, as banks perform anti-money laundering (AML) screening). Importantly, DECO protects Alice's privacy by revealing only the fact that her balance is higher than $5,000, not her actual balance or identity.
As a further example, DECO can be used to provide proof of account ownership. In one illustration of such an arrangement, with DECO, one can prove ownership of accounts, e.g., email accounts, social media accounts, etc., in anonymity. For example, Alice can prove to Bob that she owns an email account ending with @example.org without revealing what the account name is. This proves Alice's affiliation with a certain organization, which is useful for, e.g., whistleblowing, anonymous complaints, etc.
Additional examples of applications of decentralized oracles as disclosed herein include credential recovery and decentralized identity. As an illustration of the former, DECO can enable a user to prove, in a privacy-preserving manner that avoids use of OAUTH, that she has access to a particular web resource, e.g., a Facebook account. This can enable a user to leverage an existing service to prove her identity for, e.g., key recovery. As an illustration of the latter, DECO can also enable to a user to prove, in a privacy-preserving manner, that she has certain characteristics as asserted by a third-party provider (e.g., she's over 18). This is an example of what is also referred to herein as an anonymous age proof. Such a proof can be used to construct a credential in a decentralized identity system.
The foregoing decentralized oracle applications are examples only, and should not construed as limiting in any way. Additional details regarding implementation of these and other example applications of decentralized oracles as disclosed herein can be found can be found elsewhere herein.
Communications between the various elements of an information processing system configured to implement one or more decentralized oracles as disclosed herein are assumed to take place over one or more networks. A given such network can illustratively include, for example, a global computer network such as the Internet, a WAN, a LAN, a satellite network, a telephone or cable network, a cellular network such as a 3G, 4G or 5G network, a wireless network implemented using a wireless protocol such as Bluetooth, WiFi or WiMAX, or various portions or combinations of these and other types of communication networks.
A given processing device implementing at least a portion of the functionality of a decentralized oracle as disclosed herein can include components such as a processor, a 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 is to be appreciated that the particular arrangements shown and described in conjunction with
It should also be noted that the above-described information processing system arrangements are exemplary only, and alternative system arrangements can be used in other embodiments.
A given client, server, processor or other component in an information processing system as described herein is illustratively configured utilizing a corresponding processing device comprising a processor coupled to a memory. The processor executes software program code stored in the memory in order to control the performance of processing operations and other functionality. The processing device also comprises a network interface that supports communication over one or more networks.
The processor may comprise, for example, a microprocessor, an ASIC, an FPGA, a CPU, a GPU, an ALU, a 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 can 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 that 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 comprising such processor-readable storage media are considered embodiments of the invention. The term “article of manufacture” as used herein should be understood to exclude transitory, propagating signals.
Other types of computer program products comprising processor-readable storage media can be implemented in other embodiments.
In addition, embodiments of the invention may be implemented in the form of integrated circuits comprising processing circuitry configured to implement processing operations associated with decentralized oracles as well as other related functionality.
Processing devices in a given embodiment can include, for example, laptop, tablet or desktop personal computers, mobile telephones, or other types of computers or communication devices, in any combination. For example, a computer or mobile telephone can be utilized as a processing device for implementing at least portions of the functionality associated with a decentralized oracle as disclosed herein. These and other communications between the various elements of an information processing system comprising processing devices associated with respective system entities may take place over one or more networks.
An information processing 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 processing system comprises cloud infrastructure including virtual machines implemented using a hypervisor that runs on physical infrastructure. Such virtual machines may comprise respective processing devices that communicate with one another over one or more networks.
The cloud infrastructure in such an embodiment may further comprise one or more sets of applications running on respective ones of the virtual machines under the control of the hypervisor.
It is also possible to use multiple hypervisors each providing a set of virtual machines using at least one underlying physical machine. Different sets of virtual machines provided by one or more hypervisors may be utilized in configuring multiple instances of various components of the information processing system.
Another illustrative embodiment of a processing platform that may be used to implement at least a portion of an information processing system as disclosed herein comprises a plurality of processing devices which communicate with one another over at least one network. Each processing device of the processing platform is assumed to comprise a processor coupled to a memory.
Again, these particular processing platforms are presented by way of example only, and an information processing system may include additional or alternative processing platforms, as well as numerous distinct processing platforms in any combination, with each such platform comprising one or more computers, servers, storage devices or other processing devices.
For example, other processing platforms used to implement embodiments of the invention can comprise different types of virtualization infrastructure in place of or in addition to virtualization infrastructure comprising virtual machines. Thus, it is possible in some embodiments that system components can run at least in part in cloud infrastructure or other types of virtualization infrastructure, including virtualization infrastructure utilizing Docker containers or other types of Linux containers implemented using operating system level virtualization based on Linux control groups or other similar mechanisms.
It should therefore 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 collectively implemented on a common processing platform, or each such element may be implemented on a separate processing platform.
Also, numerous other arrangements of computers, servers, storage devices or other components are possible in an information processing system. Such components can communicate with other elements of the information processing system over any type of network or other communication media.
As indicated previously, components of the system as disclosed herein can be implemented at least in part in the form of one or more software programs stored in memory and executed by a processor of a processing device. For example, certain functionality associated with decentralized oracle entities or related components of a system can be implemented at least in part in the form of software.
The particular configurations of information processing systems described herein are exemplary only, and a given such system in other embodiments may include other elements in addition to or in place of those specifically shown, including one or more elements of a type commonly found in a conventional implementation of such a system.
For example, in some embodiments, an information processing system may be configured to utilize the disclosed techniques to provide additional or alternative functionality in other contexts.
Thus, techniques illustrated in some embodiments herein in the context of providing decentralized oracles for TLS can be adapted in a straightforward manner for use in other contexts. Accordingly, illustrative embodiments of the invention should not be viewed as limited to TLS or its associated processing contexts.
It is also to be appreciated that the particular process steps used in the embodiments described herein are exemplary only, and other embodiments can utilize different types and arrangements of processing operations. For example, certain process steps shown as being performed serially in the illustrative embodiments can in other embodiments be performed at least in part in parallel with one another.
It should again be emphasized that the embodiments of the invention as described herein are intended to be illustrative only. Other embodiments of the invention can be implemented utilizing a wide variety of different types and arrangements of information processing systems, networks and devices than those utilized in the particular illustrative embodiments described herein, and in numerous alternative processing contexts. In addition, the particular 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.
The present application is a continuation of U.S. patent application Ser. No. 18/652,281, filed May 1, 2024, which is a continuation of U.S. patent application Ser. No. 17/636,402, filed Feb. 18, 2022 and now issued as U.S. Pat. No. 11,997,107, which is a U.S. national phase application of PCT/US2020/048344, filed Aug. 28, 2020, and which claims priority to U.S. Provisional Patent Application Ser. No. 62/894,052, filed Aug. 30, 2019 and entitled “DECO: Decentralized Oracles for TLS.” These related applications are hereby incorporated by reference herein in their respective entireties.
This invention was made with U.S. government support under Grant Nos. CNS-1514163, CNS-1564102, CNS-1704615 and CNS-1933655 of the National Science Foundation (NSF), and Army Research Office (ARO) Grant No. W911NF161-0145. The U.S. government has certain rights in the invention.
| Number | Date | Country | |
|---|---|---|---|
| 62894052 | Aug 2019 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 18652281 | May 2024 | US |
| Child | 18897934 | US | |
| Parent | 17636402 | Feb 2022 | US |
| Child | 18652281 | US |
