Independence from centralized institutions is among the most important of the revolutionary ideas at the heart of crypto. If you keep your crypto assets in a centralized exchange, the exchange holds them on your behalf. That means complete dependence on the integrity of the exchange. If it’s hacked or collapses, your funds can disappear. 

To crypto purists, therefore, there is only one form of crypto ownership that makes sense: self-custody. Self-custody means that you have direct control of your crypto assets. In other words, you exclusively control the address in which those assets reside—and by extension the cryptographic keys that authorize transactions from that address. Those cryptographic keys reside either in a software wallet, such as an app on your mobile phone, or in a hardware wallet in the form of a USB key. 

Self-custody carries its own peril, though. By one estimate, some 20% of all Bitcoin—worth over $60 billion at the current valuation—has gone up in smoke because users have lost their keys. It’s hard to find reliable statistics, but I would wager that that’s more than users have lost in all centralized exchange failures combined.

How hard is it to secure cryptographic keys? To get a sense for this, take another kind of secret: passwords. Everyone knows how hard it is to manage and secure passwords, even with a password manager. How many times have you struggled with a lost, forgotten, or mysteriously incorrect password over the last week or month? How many times have you had to reset one?

Cryptographic keys pose even more of a challenge than passwords. If you lose a password, there’s someone—the centralized service you’re logging into—that can reset it for you. If you lose your cryptographic keys, they can’t be reset, because you’re your own help desk. 

If you embrace the crypto purists’ line and believe that self-custody is the one truly legitimate way to hold crypto assets, there’s a sobering corollary. Crypto as a technology and social movement could ultimately fail unless self-custody—and thus key management—become dramatically easier for ordinary users. 

A Little Help From Your Friends

When it comes to recovering cryptographic keys you’ve lost, maybe you aren’t an ideal help desk yourself. But what if you could enlist the aid of your friends? This is the idea behind what is sometimes called “social recovery” or “fourth-factor authentication.”¹

Social recovery is a system by which you recover your lost cryptographic keys—or other lost secrets—with the assistance of social connections, i.e., friends and family. (To be clear, it’s meant specifically to address key loss, not a different problem I won’t address here: having your key stolen.) With social recovery, a user can designate a set of helpers called “guardians,” who enable her to reset her key in case it’s lost. 

An example helps to illustrate:

Example 1: Alice uses address A for control of her collection of Cryptopunks. She generated A (and its corresponding private key SK) in a hardware wallet and uses it with a wallet contract W. Alice designates Bob and Carol as her guardians for it, enrolling addresses for them with W.

While Alice is vacationing in Hawaii, a shark swallows her hardware wallet. 

Alice buys a new hardware wallet. She uses it to generate a fresh address A* with corresponding private key SK*. She then calls Bob on the phone, asking him to help her reset her private key. She does a videoconference with Carol to make the same request. Bob and Carol each confirm Alice’s identity. By sending transactions to the wallet contract W, they authorize Alice to perform account recovery and use new address A*. (Bob uses an address AB that he holds for this purpose and Carol uses address AC.)

Thanks to authorizations from Bob and Carol, Alice has swapped in her new address A* for the old, lost address A in the wallet contract W. She is now able to use A* for control of her Cryptopunks.

As you may or may not know, it’s an odd scientific fact that your friends probably have more friends than you do. But I’m not aware of any research showing that they have better key-management skills than you do. A number of my friends are professors specializing in information security, but I’m still not sure I’d trust them entirely as a help desk—even collectively—or recommend that they should trust me.

That’s why it’s often suggested that at least some of your guardians should be institutions. But how are institutions going to be encouraged to participate in a social recovery scheme? And how are they going to authenticate users?

A Little Help From Institutions

Most of us already authenticate on a regular basis on the web to a number of different institutions—banks, social media sites, mobile carriers, and so forth. These sites have well-developed authentication systems. They’ve got user interfaces we’re all familiar with, ways to recover lost passwords, and in many cases security features such as two-factor authentication (2FA). They’re imperfect. Their users succumb regularly to phishing attacks, password breaches, and so forth. But they have state-of-the-art expertise on user authentication that it would be beneficial to leverage for self-custody—if only they could be patched into a social authentication scheme as guardians.

An institution Z might create an interface (API) that enables our user Alice to generate an address (or key share) AZ with the institution. Z then uses AZ to authorize key recovery by Alice with wallet W upon request after Alice authenticates successfully to Z. That approach would require Z to change its infrastructure to manage cryptographic secrets on behalf of users, however. Most institutions are unlikely to be willing to do that (yet).

An alternative approach is for a decentralized oracle network (DON) to manage address AZ on Alice’s behalf and authorize a key recovery for her when she proves that she has authenticated successfully to Z. But then how does Alice prove successful authentication to the DON?

One way is to use OAuth—a popular framework for authorizing access to web apps. Many institutions don’t support it for third-party authentication, though. It also raises privacy concerns. If Alice uses OAuth to authenticate to a DON, the DON will learn her account number with Z. Moreover, Z may at the same time learn that Alice is resetting a cryptocurrency wallet. 

Enter DECO. Like OAuth, DECO allows Alice to prove her ability to log into Z. DECO, however, remedies the limitations of OAuth. It allows Alice to register her account number for Z with the DON in a privacy-preserving way (via secret-sharing). It then offers two key properties: 

• Privacy-preservation: With DECO, Alice can prove to the DON that she’s logged into the account with Z she has registered without revealing her account number for Z to the DON. She also doesn’t reveal to Z that she’s authenticating to the DON.
• Universality: DECO can, in principle, enable Alice to authenticate to the DON by logging into Z without Z needing to provide explicit support of any kind, i.e., no special services or modifications to Z’s infrastructure are needed. In fact, Z need not even be aware that Alice is using DECO with Z to authenticate. 

Because Z is not explicitly involved in this process, it doesn’t send a recovery transaction to Alice’s wallet W. Instead, the DON does. That means that the DON controls AZ on Alice’s behalf.

Putting It All Together

With the powerful and flexible tools outlined here, a user like Alice can build her own help desk for key recovery, enlisting the help of friends and trusted institutions to do so. 

Example 1 illustrates a case where Alice needs to invoke the aid of all of her guardians. A social-recovery scheme alternatively allows for configuration in a threshold manner, so that only a subset of guardians are needed to effect key recovery. For example, Alice could have three guardians, of which two are needed to recover a key. This setup is often called a 2-out-of-3 scheme—and is generalizable to k-out-of-n for any desired, valid k and n. Alice can mix and match friends and institutions and also set policies that require the use of particularly important guardians, as illustrated in Example 2 and the figure below.

Example 2: To protect her address A, Alice enrolls three guardian addresses with W: Bob’s and Carol’s respective addresses AB and AC and an address AS for DECO authentication to a social media site S Alice frequently uses. The address AS is controlled by (i.e., the private key is held by) a DON. 

Alice configures W to permit recovery given authorization by S and at least one of Bob and Carol. 

Alice later loses access to her address A. To perform social recovery, she proceeds with Carol as in Example 1. Alice requests registration of a new address A* and proves her identity to Carol via, e.g., videoconference. Carol then sends a recovery transaction to W setting the controlling address to A*. To obtain authorization through the social media site S, Alice uses DECO: She authenticates to S in a protocol involving the DON. Alice doesn’t reveal her real-world identity in doing so. The DON learns only whether the user with address A has successfully authenticated to S using a registered identity associated with A. If the DON observes that Alice authenticated successfully, it sends a transaction from address AS to W to set new address A*.

Of course, a limitation of this small example is that access to S is critical to recovery. If she wants more flexibility, Alice can of course instead enroll multiple institutions and require successful authentication to only a subset in order to perform key recovery.

Figure: Example social recovery setting. Alice has three guardians: friends Bob and Carol and institution S, a social-media site. She has enrolled respective guardian addresses AB, AC, and AS with her wallet W. To have Carol authorize recovery, Alice contacts her and has her generate a transaction swapping in Alice’s fresh address A*. To authorize recovery using S, Alice invokes DECO. She authenticates to S and proves successful authentication to the DON, which then sends a transaction to W from address AS authorizing instantiation of address A*. 

Conclusion

Social recovery will almost certainly be a prerequisite for self-custody to become popular and sustainable. It’s nice to be able to rely on friends and family as your virtual help desk for this purpose. Nicer still, though, is the ability also to enlist the help of the pros, the websites we use on a daily basis and already rely on for strong, usable authentication. With DECO, it’s possible in principle to do so in a privacy-preserving way with any site of your choosing.

Notes

¹ The traditional three factors are something you have, something you are (biometrics), and something you know. The fourth factor is somebody you know.

To learn more about Chainlink and keep up with the latest smart contract research and innovations, subscribe to the Chainlink newsletter and follow the official Chainlink Twitter.