One of the biggest challenges facing the blockchain ecosystem is the vital importance of keeping account keys safe. If your keys are lost or compromised, you lose everything. But it doesn’t have to be that way.

With traditional banking systems, if you lose your bank card you can cancel it and order a replacement. If someone else gets a hold of your bank card, your bank is on the lookout for suspicious activity and will check with you if things seem off. The downside is that you also have to trust your bank to give you access to your money when you need it.

With blockchain technology, your keys are like your bank card, but you can’t cancel your keys an order a replacement. If someone else gets your keys, they can take off with everything you’ve got before you have a chance to do anything about it. But so long as you keep your keys safe, nobody can control what you do with your digital assets.

Smart Contracts

In Ethereum we can use smart contracts to give us some of the advantages of traditional bank cards, while still keeping complete control of our accounts. Instead of keeping assets in accounts managed by private keys, you can keep your assets in contracts with access control rules that give you more fine grained control of your assets.

Canceling Lost Keys

For a basic example, let’s start with a contract that has a master key and several other restricted keys.

In this case, the master key would be needed to add or remove restricted keys, but the restricted keys can be used to send transactions from your contract. You could keep one key on your laptop, another on your cell phone, and a third on your work desktop. After you’ve added your restricted keys, the master key goes in a safe or gets locked in your desk drawer.

On a day-to-day basis, you can access your digital assets from the devices you have around you all the time. But one day you get home from dinner and realize you left your phone at the restaurant. It’s protected by a PIN, but sooner or later someone could get your key off of it.

No worries. You go to your safe, get out your master key, and use it to revoke your the restricted key on your cell phone. Now it doesn’t matter if someone lifts the keys off your cell phone, the contract won’t accept transactions from it anymore.

Two-Factor Authentication

But what if someone got into your phone before you realized you’d lost it. If your restricted keys have unfettered access to your assets, your account might be empty by the time you notice. We can add another layer to protect against this.

Now we have the master key, which can add keys both to the list of your devices and to the list of “verifiers”. Now for your contract to consider a transaction valid, the transaction must be signed both by one of your devices and by one of your verifiers.

When you want to send a transaction you sign it with one of your devices, but instead of broadcasting it to the network you send it to one of your verifiers. They apply a set of rules to decide how to proceed:

• If it’s a $3 transaction to the coffee shop you visit every morning, they sign the transaction and submit it to the blockchain.
• If it’s a $20 transaction to a restaurant you’ve never been to before, they text you a link and ask you to put in your password before signing the transaction and submitting it to the blockchain.
• If it’s emptying all the tokens and Ether in your account they call you, ask you some security questions, then send you an e-mail with a cancellation link. If you haven’t clicked the cancellation link in 24 hours, they sign the transaction and submit it to the blockchain.

These rules aren’t governed on the blockchain. It’s up to the verifier to decide whether or not they sign a given transaction. Maybe you and the verifier have agreed to a set of rules about what steps to take given a transaction pattern. Maybe you’re paying them to insure your account against theft (at least through transactions they sign), and use their own heuristics to decide how to handle each transaction.

You don’t have to place too much trust in your verifiers. You want them to protect you in the event that one of your own devices gets compromised, but they can’t steal your assets since they don’t have your device keys, and if they try to censor a transaction you really want to go through you can use your master key to add a key of your own to the verifier list and send the transaction through yourself.

Account Recovery

Now the unthinkable happens. Your house burns down. All your devices are gone. The master key that was locked in your desk drawer is gone. How can you recover from this?

If you had set up a recovery plan in advance, you still have options.

Following in the footsteps of KeySplit, we designated guardians to help us recover our account. In this case we set up three groups: Family, School Friends, and Colleagues. In each of these groups we can list as many trusted accounts as we like. When you need to recover your account after a fire, you need to get one signature from a verifier, as well as an approval from one family member, one school friend, and one colleague. Then the contract will allow you to set a new master key, and from there you can set up new device keys.

Like with KeySplit, we want to require approvals from guardians in different parts of your life. At least in my case, Family, School Friends, and Colleagues are mostly disparate groups. While some of my old school friends might know each other well enough to collude to steal my account, they don’t know my family or colleagues well enough to get them to collude against me as well. And if my old college roommate approached one of my current colleagues to help steal my account, I feel reasonably confident that my colleague would say “Hey, did you know this guy is trying to break into your Ethereum account? Maybe you shouldn’t have him as a guardian.”

What’s more, the approvals you get from guardians could be sent to your contract from other contracts. While your devices and verifiers should have keys to streamline regular transactions, the approvals you get to reset your master key could come from other contracts similar to the one you’re recovering. This could potentially mean that after you add a friend to your list of guardians, they could change every key associated with their account, but still have the same address when you need their help recovering your account.

Privacy

One of the downsides of the approach described above is that anyone can see relationships between accounts, the people you designate as guardians can know what account they are a guardian for. To mitigate this instead of storing guardian’s addresses directly, we could store a salted hash of the guardian’s address, where the salt is derived from some simple password you could remember if an account recovery became necessary. When you asked a guardian to recover your account you could provide them with the salt, and the contract could verify that the salt plus their account address hashes to the stored hash.

Making This Happen

There are a lot of challenges in the way of making this kind of smart contract a reality.

First of all, it’s complicated. If a company like Parity has trouble with a comparatively simple multisig wallet, there are going to be a lot of challenges getting a contract like this right. It would need to be reviewed by a lot of talented security experts before I’d be comfortable trusting my assets to it.

Another major challenge has to do with standards. Most DApp users today access DApps with a browser plugin like Metamask or a mobile browser like Toshi or Cipher. Those providers know how to sign transactions provided by DApps and send them to the blockchain, but there’s currently no way to route your transactions through a contract that will handle your transaction, or send them to a third party verifier instead of the blockchain.

There’s a lot of discussion in the Ethereum community about a concept called account abstraction, which I anticipate will be the first step towards establishing standards for routing transactions through contracts instead of just signing them and broadcasting them to the network.

If this is something you’d be interested helping to make a reality, please reach out to me by e-mail, Gitter, reddit, whatever. OpenRelay keeps me busy enough that this is likely to stay deep in my backlog for the foreseeable future, but I’d love to offer help and guidance to anyone interested in taking charge on this kind of project.