Research Summary - DECO: Liberating Web Data Using Decentralized Oracles for TLS

Citation

  • F. Zhang, D. Maram, H. Malvai, S. Goldfeder, and A. Juels. DECO: Liberating Web Data Using Decentralized Oracles for TLS. ACM SIGSAC Conference on Computer and Communications Security (ACM CCS), pp. 1919–1938. 2020.

Link

Core Research Question

  • How to enable a third party (e.g., an oracle node) to access private web data (or be convinced by statements about such data) without revealing user credentials?
  • This paper presents DECO (DECentralized Oracle). 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. DECO is the first such system that works without trusted hardware or server-side modifications.

Background

  • Nearly all existing oracle systems today lack confidentiality, in the sense that they require oracle nodes to have direct access to the sources of data they use to generate reports. Consequently, such systems cannot make secure use of privacy-sensitive data. Existing systems that do provide confidentiality rely on trusted execution environments, whose recent vulnerabilities have prompted serious concerns.
  • DECO is a cryptographic protocol that permits users to prove statements to oracle nodes in zero-knowledge about data obtained over secure internet connections (TLS) from unmodified web servers. Users can thus make trustworthy assertions to oracle nodes and support report generation based on private data in existing systems without revealing the data directly.

Summary

  • TLS (Transport Layer Security) is a pervasive cryptographic protocol used to provide end-to-end security between clients and web servers. It lacks one important feature, however: It does not digitally sign data. Consequently, there is no existing means to export data from a TLS session to a third party in a verifiable way without revealing user credentials.

  • Example: A user may wish to prove to an oracle system that she is at least 18 years of age (and thus eligible to participate in a DeFi protocol). She can log into her state’s Department of Motor Vehicles (DMV) site and view an authoritative record of her birthdate B there, but cannot prove her birthdate to another party (unless she reveals her username and password).

  • DECO’s main technical contribution is a new three-party handshake protocol. The protocol involves a prover, verifier, and website. It enables the prover and verifier to establish a cryptographically (secret-)shared client TLS key in a session with the website so that the prover can prove statements to the verifier about data served by the website. In the above example, the user can prove her birthdate B to the verifier.

  • DECO allows the prover to prove statements about data D in a TLS session in zero-knowledge. In the above example, the prover can prove that she is 18 years of age, without revealing B.

  • The paper focuses on efficient DECO proofs for the special but common case of selective opening, meaning that D is truncated or redacted to a substring D’. Another technical contribution is a set of techniques to ensure context integrity for D’, meaning that D’ appears in a context expected by the verifier. In the above example, B is meaningful if it appears in the date-of-birth field of the user’s DMV profile, but could be falsified if it appears, for example, in a comment submitted to the site by the user.

  • Main application: As its name suggests, one of DECO’s main applications is support for decentralized oracle networks. A network of oracle nodes can convert DECO proofs from a user into a report that reflects TLS data served to the user. For example, in the figure below, a user provides (three) DECO proofs to three oracles nodes that her bank account balance, as reported by her bank’s website, is greater than $5000. The nodes collectively sign a report asserting the proven bank balance.

Method

  • The emphasis of the paper is on the introduction of new protocol design techniques. It also includes supporting formalism and security proofs, as well as experiments.

  • The main technical contribution of the paper is the three-party handshake protocol. In this protocol, the prover and verifier generate a secret-shared (symmetric) client TLS key K. They hold respective shares KP and KV.

  • The three-party handshake protocol is transparent, in the sense that the website is unaware of its execution and even unaware of the existence of the verifier. This feature is what enables DECO to work with legacy, i.e., unmodified web servers.

  • The three-party handshake protocol involves several steps. First, the two players use the additive homomorphism in elliptic-curve-based Diffie-Hellman (DH) key agreement to obtain an additive sharing over EC(FP) of DH secret Z = ZP + ZV, where ZP is the prover’s share and _ZV _is the verifier’s. In other words, Z is the sum of two elliptic curve points. In the second step, the players engage in a secure two-party protocol to convert their additive sharing in EC(FP) to an additive sharing of the x-coordinate of _Z_over FP. Finally, they perform a secure two-party computation on this latter value, applying the key-derivation function of TLS (a pseudorandom function (PRF)) to obtain respective key shares KP and KV.

  • The paper describes optimizations for DECO proofs based on a selective opening D’ of data D. Such selective opening raises the challenge of ensuring context integrity, as noted above. The paper introduces a technique called zero-knowledge two-stage parsing to ensure this property, and presents examples for a grammar that reflects the common use of key-value pairs in web APIs.

  • The paper presents three example applications for DECO, including two in particular for blockchain systems: (1) A confidential, smart-contract-based Binary Option based on target asset prices kept private from oracle nodes; and (2) Converting credentials in existing web servers to anonymous credentials usable in decentralized-identity systems, e.g., an Age Proof that a user is over age 18 as in the example above.

  • The paper describes optimizations for DECO proofs based on a selective opening D’ of data D. Such selective opening raises the challenge of ensuring context integrity, as noted above. The paper introduces a technique called zero-knowledge two-stage parsing to ensure this property, and presents examples for a grammar that reflects the common use of key-value pairs in web APIs.
  • The paper presents three example applications for DECO, including two in particular for blockchain systems: (1) A confidential, smart-contract-based Binary Option based on target asset prices kept private from oracle nodes; and (2) Converting credentials in existing web servers to anonymous credentials usable in decentralized-identity systems, e.g., an Age Proof that a user is over age 18 as in the example above.

Results

  • Experiments reported in the paper demonstrate the practicality of DECO for the example applications put forth in the paper. For example, over a wide-area network (WAN), the three-party handshake protocol requires approximately three seconds of online execution for use with TLS 1.2. (It also requires about ten seconds of offline computation by the prover and verifier.) Generation of zero-knowledge proofs is similarly resource-efficient, as shown in the following table reflecting the application examples mentioned above.

Discussion & Key Takeaways

  • DECO promises to “liberate” private data from centralized web-service silos, exporting it and making it accessible to a rich spectrum of applications, including oracle networks and thus smart contracts.

Implications & Follow-ups

  • DECO has a number of compelling applications that are under exploration at Chainlink and in the academic literature, as seen in recent work on CanDID, a decentralized identity platform.

Applicability

  • DECO provides unprecedented confidentiality for smart contract applications. It enables Chainlink oracles to verify statements about sensitive data residing on websites without direct access to the data itself. Use cases include: (1) Private financial instruments whose terms are concealed on-chain and from oracle nodes, (2) Private decentralized identity, where personal credentials are based on data in online user accounts; (3) Transferrable APIs, where one oracle with private access to data can export its data in an authenticated manner to other oracles. In general, DECO makes data from traditionally centralized silos available to the growing blockchain ecosystem while ensuring confidentiality.
3 Likes

In describing “decentralized” in the blockchain space, many projects seemed to have been attempting to create distributed networks rather than “decentralized”. This project seems to be moving towards an actual distributed network, which is technically more “decentralized” than the “decentralized” network structure. DeCO seems to be moving towards “distributed” blockchain oracles rather than “decentralized” since the handshake protocol is symmetric instead of asymmetric if I am reading correctly; or is it actually manifesting a “decentralized” model where many oracles were claiming decentralization, but were actually more “centralized” in their execution?

image

2 Likes

@Larry_Bates, cheers for the thoughtful response.

It’s my understanding that DECO’s implementation within Chainlink will be backed by heterogeneous networks of nodes, which would lend to decentralized operation. I expect there will be a roster of DECO enabled nodes that a dApp developer could choose from, and anybody could spin up their own DECO enabled node. Your dApp will make use of a group of nodes of your choosing, selecting them based on your own criteria from resources like Market.link and Reputation.link. Another developer could spin up their dApp, and select an entirely different group of nodes to form their own DECO enabled oracle.

2 Likes

DECO is a very exciting technology, especially in the context of canDID and decentralized identity in general. Being able to cryptographically and definitively prove who you in a privacy preserving manner using existing data silos, but without server-side modifications, is not something we’ve ever had before and really has broad implications for the crypto space as whole.

The most likely initial application I see of DECO is for enabling privacy preserving DeFi applications geared towards institutions. Not only in the sense that they can keep their backend data private while still being able to use it in the execution of contracts, but also in the sense that they can offer DeFi services to clients in a KYC/AML compliant way through DECO, without actually revealing their personal information on-chain or to the institution. This also brings another benefit in that institutions no longer have to custody and secure sensitive user PII, which has time and time again been leaked by negligent firms like Equifax. So really it’s a win-win for both the institution and the end-user.

I think DECO pairs well with Chainlink Mixicles, which provides on-chain privacy through a mixer design, as together it creates an end-to-end privacy solution for global institutions to dip their toes in DeFi in a practical manner that fits their needs. I’m curious what others think about the major implications of DECO.

5 Likes

I’ve had some people reach out to me asking about the potential use of Deco where the end result isn’t a smart contract, but a web-app. Do we know if this will be possible? ie to have a web-app that requires some kind of proof (eg does Alice have enough funds in her bank account)

3 Likes

Great question, I expect that this would certainly be possible. Relaying that information to a smart contract is more complicated than relaying that information from one web app to another web app, so I imagine it would just be a matter of implementation.

2 Likes

Certainly. One example is decentralized identity: Cryptology ePrint Archive: Report 2020/934 - CanDID: Can-Do Decentralized Identity with Legacy Compatibility, Sybil-Resistance, and Accountability.

5 Likes

Welcome to the forum @fanz thanks for the link to the canDID paper. It seems like you, @Eric, and @Zach see upsides to DECO and canDID working together. Could you elaborate on that a little more? Any unintended consequences we might also want to be looking out for?

2 Likes