How to kill Equifax
Or, “Autonomous data privacy”. Part 5 of a series on “Privacy on the Blockchain”.
We’ve discussed two different approaches to data privacy in smart contracts — zero-knowledge proofs, including zk-SNARKs, and private blockchains.
zk-SNARKs allow smart contracts to offload data privacy to users, while requiring them to prove that their computations are valid by the rules of the contract. Private blockchains, on the other hand, change the rules of the game — allowing application data privacy while forfeiting the benefits of a public blockchain.
zk-SNARKs are a powerful tool toward building privacy-aware systems on public blockchains, but they aren’t enough for many organizations to abandon private ledgers. That’s because in many business cases, there’s not a correspondence between users and data access.
Let’s talk about one such case.
Killing Equifax
Recently, Equifax suffered a horrible security incident, exposing up to 143 million people’s personal information, including Social Security, driver’s license, and credit card numbers.
Actually, that’s not quite right. Because Equifax’s business doesn’t rely on consumer trust, they haven’t suffered yet — though the 143 million people affected certainly will. The scope of the attack is difficult to understate, and it’s left many questioning whether large, disinterested corporations like Equifax can be trusted with so much of our personal information.
The problem the Equifax hack exposes is structural to our economy. When a consumer applies for a loan, or opens a new credit card, the potential lender wants to make sure the consumer is credit-worthy. Because there are many lenders, they can’t ask every other lender whether the consumer missed a payment. In fact, those other lenders are their competitors, and aren’t interested in helping them assess risk.
To solve this problem, consumer credit reporting agencies — the most well-known of which are Equifax, Experian, and TransUnion — collect information from past lenders, landlords, utilities, and other parties to compile a consumer’s credit report. Lenders can pay for this report to decide whether to extend a loan, and even pay for access to high-scoring individuals to whom they can advertise their services.
Unfortunately, in this system, credit agencies’ incentives are aligned almost exclusively with their customers — the lenders. They don’t have a strong incentive to protect consumers’ personal information.
A step-by-step guide to replacing your credit agency
The credit agency problem sounds like a good fit for a blockchain. There are competing parties — lender vs consumer, lender vs lender, and consumer vs hacker. Lenders want information on consumers, but don’t want to help competitors assess risk. Consumers want access to credit, but don’t want their personal information to fall into the wrong hands.
In situations like this, blockchains can act as arbiters. But without delegated computation, consumer privacy needs fall to the wayside.
Imagine for a moment we have the privacy technology we need. Contracts can offload access to private data, and request computations over that data. With this new tool, we can build an autonomous credit agency.
1. Identity
We need a way for consumers to assert their identities. A system like Civic means consumers can keep private information on their mobile devices. Identity verifiers request access to that information, which consumers grant via a mobile app. The verifiers then assert that the mobile device and associated public key are, indeed, owned by the person the consumer claims to be.
In this system, more verifiers means better security. The power company can assert you live at an address, based on billing and account history. The Social Security Administration, the State Department, or your local DMV can assert other facts about your identity based on verifying ID cards. While any one verifier might be hacked, it’s unlikely they all will.
2. Credit history
Now that we have a strong identity framework, we can tackle credit history. Lenders can assert facts about their interactions with a consumer. These assertions may or may not be true — even the best-intentioned lender could have a mix-up — but they’re a best effort.
3. Dispute resolution
Consumers can challenge assertions. In the case of a challenge, the assertion goes to arbitration. Lenders must substantiate their claims. For consumers, most disputes will be simple— if a lender can’t substantiate their claim, or they don’t bother, the assertion is struck.
Assertions about a consumer’s credit shouldn’t be public. Lenders commit to an assertion on the blockchain, and encrypt assertions with a consumer’s public assertion key.
Congratulations, we’ve imagined the pieces of a decentralized credit system. But how can lenders use this system for risk assessment?
4. Replacing credit reports
A lender considers a loan application. They have the borrower’s public key, as well as records linking their public key and their real-world identity.
The lender wants to review the borrower’s history, using their own in-house risk assessment function to decide whether to back the loan. But the borrower doesn’t want to expose their entire credit history to the lender — not only could they lose it to hackers, but the details are none of the lender’s damn business.
By delegating the computation to another party, the lender can be sure the data has been properly evaluated, scoring the borrower for a loan, and the borrower can get their loan, only exposing their credit history to the non-lending party.
Now we’ve found the crux of this whole scheme. We’re ready to knock this mother down, and replace consumer credit agencies with a fairer, more secure alternative. We just need to find a way for the lender and borrower to delegate computation without exposing the borrower’s credit history to prying eyes, or the lender’s scoring function to competitors.
Multi-party computation
Secure multi-party computation (sMPC) is a class of cryptographic techniques that allow untrusted parties to work together to securely compute the output of a function.
sMPC was originally devised by Andrew Yao to solve what he called the Millionaires’ Problem.
The problem works like this. Two millionaires are chatting, and wondering which of them has the greater wealth, as millionaires are wont to do. Neither will disclose their financial position, but they both want the bragging rights of being the wealthiest.
Instead of comparing watches or counting lambos, Andrew Yao proposed a new solution. The first millionaire enters the details of their wealth as one input into a Boolean circuit, then encrypts the result, constructing what’s called a garbled circuit. The second millionaire inputs their wealth into the garbled circuit. The result can be decrypted by the first millionaire, proving which millionaire is wealthiest — no conspicuous consumption necessary.
This discovery led Yao to pioneer an entirely new field of cryptography. As the field matured and began yielding practical results, new, more efficient MPC protocols were found.
Secret-sharing
Yao’s garbled circuit protocol relies on a Boolean circuit. A Boolean circuit is a series of logic gates, similar to the low-level foundations of modern computing. Unfortunately, Boolean circuits aren’t as expressive as general functions, and don’t allow loops or conditional logic.
Newer MPC protocols have also been discovered for arithmetic circuits. Instead of being built out of logic gates, arithmetic circuits are built on addition and multiplication operations. Each arithmetic circuit has a corresponding Boolean circuit, and vice versa, but arithmetic circuits are a much better fit for functions that include a lot of exponentiation, like many popular cryptographic protocols.
Here’s a simple sMPC scheme, based on Shamir’s secret sharing. Given a secret, S, split it into 5 pieces such that each piece is a 2-dimensional point, and give each piece to a different person. Together, those 5 points uniquely describe a 5th-degree (quintic) polynomial, representing our secret. In the literature, the party splitting the secret is called the trusted dealer, and the secret pieces are called shares.
Now, we’ve split our secret so it can’t be recovered without all 5 people colluding. How can we compute an arithmetic function in this scenario?
It turns out addition is straightforward. Because each share is a linear polynomial, each party can perform addition locally.
Multiplication, however, is a little trickier. The first step in a multiplication can be performed locally, just like addition. The resulting polynomial is quadratic, though, preventing future addition. To remedy this, parties perform a communication round, splitting the results of their local multiplication between each other party, reducing the order of the polynomial.
Now that we have addition and multiplication, we can represent most computation.
For a more rigorous treatment of secret-sharing sMPC with arithmetic circuits, check out Vitalik’s “Secret Sharing DAOs: The Other Crypto 2.0”.
Malicious parties
sMPC protocols based on secret-sharing offer huge performance improvements over other garbled circuits. However, while they prevent the computing parties from learning the secret they’re operating over, they don’t prevent a malicious party from returning false data, ruining the computation.
Fortunately, this is the perfect use case for zero-knowledge proofs! Modern sMPC protocols can require each party to include a zero-knowledge proof of their computation, making the protocol secure, even against malicious parties.
Multi-party computation and the blockchain
Though secret-sharing based sMPC protocols can maintain data integrity with zero-knowledge proofs, they still suffer from data withholding attacks. A malicious party can withhold their share in the final computation of a function, obtaining access to the output of a computation unfairly, or aborting a computation entirely.
In the last 8 years, however, we’ve been given a tool to ensure fairness — the blockchain. By requiring each party to include a security deposit at the beginning of a computation, we can punish malicious parties for data withholding attacks.
Multi-party computation is the missing key to autonomous privacy on the blockchain. And, it turns out, the blockchain fixes a core issue holding back multi-party computation from wider spread usage.
I believe the marriage of these technologies can end privacy tradeoffs on public blockchains, unlocking entirely new consumer applications, and providing the enterprise an alternative to private ledgers. Privacy-enabled blockchains can be the end to companies like Equifax, abusing consumer information and seeking rent on our entire economy.
With those goals in mind, I’m happy share the latest leg of our journey at Fold.
Announcing the Keep network
I’m excited to announce the Keep network, our effort to bring private computation to public smart contracts.
Keep sprung out of our work at Fold building a decentralized exchange for gift cards. As we dug into the space, we became frustrated with the privacy status quo. Simple scenarios like sending private information between users were straightforward, but the real world requires complex escrow schemes, market makers, and other autonomous components that required custody of private information. It was clear we couldn’t keep hacking around the public blockchain, and needed to address the privacy issue directly.
When we understood the scope of what we were building, we knew we couldn’t limit our ambition to gift cards. We’re building tools to reshape the modern economy.
If you’re interested in continuing with us on our journey, follow along on the blog, where we’ll continue to explore privacy-related topics, check out the whitepaper , or join us on Slack.
Thanks to Laura Wallendal, Corbin Pon, Antonio Salazar Cardozo, and Brayton Williams for reviewing early drafts of this post, and James Peerless for catching copy mistakes.
[1] Good examples of this pattern today are the Edge Security model by Airbitz and the Civic app.
Learn More
For more information about the Keep Network:
- Join us on Reddit.
- Check out our whitepaper.
- Read our business primer.
- Subscribe for email updates.
- Follow us on Twitter.
- Join our Slack.
- Join our Telegram.
