Ari Juels DECO Presentation: Liberating Web Data Using Decentralized Oracles for TLS

(upbeat music) – Hello, I'm Ari Juels. I'm delighted to be with
you here today at Smart Con in my new role as Chief
Scientist of Chainlink. In fact, I'm doubly delighted because as was announced earlier today, I'm gonna talk about DECO, a technology developed in my separate role at Cornell Tech in IC3 that
Chainlink has just acquired. To explain what DECO is, let me first give you a motivating example involving cryptographers'
two favorite people, Alice and Bob. Now Bob is about to launch a new token called Bob's Bubble Token, and he's gonna be holding a token sale. Bob has particular ideas about how to make his
token sale responsible. He wants to ensure that his
tokens are fairly distributed. They're not all snapped
up by Will for instance, and that people who participate can reasonably afford to do so. So he sets the following rule. So buy up to 100 BBT, you have to show that
there's a bank account with your name on it, that
contains at least $5,000. This makes it hard for people to create fictitious identities.

And it's also a kind of accreditation. We won't worry about
concealing names at this point. Now Alice would very
much like to participate in this most promising of token sales. So she logs into her bank account online and checks her balance, and she discovers lo and behold that she has more than $5,000. So she goes to Bob and says, "Hi Bob, I've got more than
$5,000 in my bank account." Naturally Bob's response is the question, "Can you prove it?" So how can Alice prove to Bob that she has a bank account
with at least $5,000 in. First idea is for Alice
to take a screenshot of her bank account
balance and sent it to Bob. But this is a problem. And that it's relatively
easy to modify a screenshot using say, Photoshop. Alice might have no money in her account, and yet pretend to be a multimillionaire. So clearly this isn't gonna work. Another possibility is that Alice sends her login credentials, her username and password to Bob. Bob then logs into her accounts and checks her account balance.

Now this works, but it's a bad habit for Alice to get into if she wants to keep her bank
account balance above $5,000. So that's not quite gonna work. We observe though that when Alice logs
into her bank's website, she's almost certainly using HTTPS. This means she's establishing
a secure connection with the bank via TLS. That's the protocol that's
used everywhere on the internet to secure data. In TLS, the server presents
Alice the certificate validating its identity in a public key. And in the course of the
key exchange protocol or the handshake, it's
digitally signing a message. This is all well and good, especially the use of digital signatures.

And it seems like we might
somehow be able to leverage TLS to solve our problem of authenticating Alice's
bank account balance to Bob. But there's a problem with TLS. It does indeed use public key cryptography and digital signatures
to perform key exchange, but this is to exchange
symmetric keys for the session for what's called the record layer. In other words, when data is exchanged
between Alice and the server, it's secured using a key
that the two of them share. They're using what's called a MAC or a message authentication code rather than the true signature. Consequently, Alice is just
as capable of signing data in this sense at least, as the bank is.

There's no digital signature
on data that can be shown to a third party to provide
trustworthy proof about the data provided by the bank or
the server in this case. There are proposals to change TLS like the very nice TLS
scheme from ETH Zurich and schemes like open ID, sign some data, but in general, to get the
kind of widespread data signing we'd like to have for an oracle network would require a big
infrastructural changes and practical ones.

And in fact, digitally
signing data isn't good enough because of confidentiality requirements as we'll see in just a moment. So to summarize here, forwarding TLS data to Bob is
no better than a screenshot. Again, because Alice is just
as capable of signing data as the server is. As a result, there's lots
of unusable private data sitting in web servers. Things like bank account balances
and identity information, identity documents like driver's licenses and private enterprise
data or private APIs. This situation is really
frustrating for oracle builders. Having data locked up
this way is a frustration. Our solution to this problem
is this system called DECO. What DECO aims to do is
liberate this data if you will. So it can be used in blockchain
systems and elsewhere. Specifically, we want to use it to be able to log into a website via TLS, and then prove statements
about the data she receives to a verifier using zero knowledge proofs. For instance, in our banking example, we'd like Alice to be able to prove to Bob that she has more than
$5,000 in her account, ideally without even revealing
her bank account balance.

And we would like to do
this with no modification to the server. That way we can build on
a seen infrastructure. But wait a minute, didn't I
just say the TLS can't do this? I did, but DECO sidesteps
the limitations of TLS using some tricks that I'll explain. So let's take a glimpse
under the hood of DECO. Let me spend a few minutes
explaining how it works.

You don't need to understand
any of this explanation to grasp what DECO does, but I'd like at least
to convey some flavor of its mechanics. The key idea is something we
call a three-party handshake. And explaining what that is, I'm gonna refer to Alice
and Bob alternatively, as the prover and verifier, because those are the roles
that they'll be playing in the protocol here. When Alice or the prover
logs into a website, the session key she
establishes with the server is going to be split on the client side between the prover and verifier.

The session key, this all critical key, is gonna be equal to the sum of shares held by Alice and Bob. Neither of them will know
the key in its entirety. In order to make this happen, the prover and verifier need to interact in a way I'll describe. Now I'm not gonna describe
the full protocol, which is pretty complicated, I'm just gonna describe a tiny piece to give you some intuition
for how it works. In a normal TLS key exchange, the client randomly
generates a private key, which we'll call X.

She then computes the
corresponding public key Y, and she sends this to the server. This Y or Yclient. In DECO, what happens
is something like this. The verifier first generates
his own private key, Xv at random, computes the public key and sends that corresponding
public key to the prover. The prover then generates
her own private key Xp and computes the
corresponding public key, Yp. And what she sends to
the server is the product of her public key and the
verifier's public key. Thanks to an additive homomorphism here, the private key X
corresponding to Yclient, the public key sent to the server is exactly the sum of the
private key of approver and the private key of the verifier.

So we've split the private key here. Now, again, this is only one tiny piece of the larger protocol. The full protocol is much more involved because then the value
X needs to be converted into a symmetric session
K and so on and so forth. But what I've presented here is enough to get the basic idea. So the intuition is that Alice and Bob generate this shared
key K, the TLS session, and they use this shared key
in a joint manner, securely. They can do things like
decrypt data for Alice. The protocol is such that
Alice can't forge data from the server, because she doesn't know the
session key at a critical time, but she can prove things
about the data provided by the server to Bob in zero knowledge. And all of this again is
transparent to the server. The server doesn't see any
of this stuff shaded in gray. It has no idea that there's
an interactive protocol happening on the back end.

As far as it's concerned, it's talking to a
perfectly ordinary client. All of this gives us a
refined picture of DECO, involves two steps. First, the user logs
into the target website while performing a three-way
handshake with a verifier, proven verifier. And then the prover can prove
things in zero knowledge about the data she gets from
the server to the verifier. How then do we use DECO in
a full blown oracle network? Suppose we have a set of
oracle nodes, chain link nodes. And suppose this before that Alice wants to prove that her bank
account balances about $5,000. It's very simple. All she needs to do is
generate DECO proofs for these three nodes, proves
to each of them individually that her balance is about $5,000 and they can then collectively
using a threshold signature or whatever you like sign a report saying that they saw a valid proof. And of course Alice, because of the use of
zero knowledge proofs, doesn't need to show her account balance directly to the oracle nodes.

All they learn or anyone learns is that her account
balance is about $5,000. But now I'm going to talk about three other different example applications that illustrate how DECO can
be used in an oracle network. The first such example is
private enterprise data. Let's take a supply chain example. Now enterprises wants to
connect to blockchains, but have concerns about confidentiality. And this example is meant
to illustrate the point.

Alice is responsible in this example for shipping some goods. We'd like to take advantage of
the power of smart contracts by having her paid automatically
when the goods arrive. But there's a critical
confidentiality issue here. The goods are say some rare
and highly valuable commodities that are nearly impossible to
get during the COVID-19 era. So she doesn't wanna advertise on chain that she's shipping them. Something like say kittens, or maybe that's too implausible. Nobody can get a kitten these days. So let's say gold bars, right? Alice doesn't wanna reveal on chain or to the oracle nodes, that
she's shipping say two tons in gold bars.

So the shipment details can be represented in some cryptographically
concealed form in the contract. We'll call this representation C. Now Alice is shipping these bars using a service called Bob's Big Boats. Somehow she needs to get data about the shipment of the gold bars from Bob's Big Boats to the contract in a trustworthy and confidential way. You can easily see how she
can use DECO for this purpose. She logs into Bob's website, executes DECO with the oracle network to prove that the shipment
specified on the contract in that critical value C has arrived. And that's it. And you'll observe that again because of the use of zero
knowledge proofs here, we can completely conceal the
existence of the gold bars, conceal all the critical shipping details.

Example two involves
what's often referred to as decentralized identity. Suppose that Alice wants to
take out a loan from a bank and needs a credential proving that she's over 18 years of
age, a requirement to do this. She can generate such a proof using DECO. What she does is log into a few websites with an authoritative
record of her birth date and she uses DECO then to
prove to the oracle network that she's over 18 years of age.

The Oracle network then generates a report saying Alice is over 18. This trustworthy report
can be used as a credential for Alice to take out her loan or for any other similar purpose. And again, we get confidentiality here. Using zero knowledge proofs means that Alice doesn't have to reveal to the oracle nodes, her exact birthdate. She just proves to them that she's over 18 and that's all they wanted. We can use exactly this approach to generate decentralized credentials from any authoritative website. Again, with no modification
of the website. And this seems like a really good way to bootstrap a decentralized
identity ecosystem. Our final example involves
confidential DeFi. Suppose that Alice and Bob wants
to execute a binary option.

What do I mean by this? I mean, they wanna make a bet
on the value of some asset X. If X rises, then Bob
pays Alice say 100 ETH. If X falls or stays the same,
Alice pays 100 ETH to Bob. This is pretty easy to
do using a smart contract and the help of an oracle network. The two players here, Alice and Bob, each deposit a 100 ETH
into the smart contract. And then the oracle network checks the value of the critical asset, relays it to the contract
and a winner gets paid. This is relatively simple. But what if Alice and Bob
don't want the oracle network to learn what exits, what
asset they're betting on.

What they can do is the following, They store in the smart
contract a commitment, a cryptographically concealed
representation of X, along with the contract terms. In other words, the terms that
determine who wins the bet. And then the winner of
the bet, Bob in this case, can contact a trustworthy
website or multiple websites and use DECO to prove
to the oracle network that he gets the money. The critical feature we
get from use of DECO here, is that the Oracle
network doesn't learn X. And we can also conceal
the terms of the contract. Before I wrap up, I want
to emphasize to be clear, that there's one thing that DECO can't do. A user can't log into a
website, and then unilaterally, to say on her own generate
a trustworthy DECO proof that she can then put directly on chain.

DECO cannot generate
such a proof directly. You need to have the
oracle network and bloop. (slow music).

You May Also Like