Replacing Passwords with People
At Uno we really don’t like passwords—so much so that the entire basis for a user account is the 256-bit seed of unguessable, uncrackable, raw entropy. Like with a crypto wallet, if that seed is lost you’re not getting back in to your vault. You can’t email a support team and request access back, and you can’t impression the lock, manually drill through a safe door, or call your car dealer and have them make a new set. It’s gone and you must make a new account and new vault. Securely storing keys is one of the more fundamental problems facing the transition away from password credentials. And oddly, in practice, hackers are far from the most pressing issue regarding protecting cryptographic keys.
The biggest threat vector is actually... you. Well you, and mother nature, and acts of god, and what have you. In reality a user is far more likely to lose their seed entropy because they forgot to migrate it to a new phone than they are to someone guessing or stealing it. And not even slightly, we’re talking orders of magnitude. It’s a scary thought: you are a single point of failure.
The answer to these type of threats is redundancy. If you store your key securely in enough spots and on enough devices then the odds tip in your favor in terms of retaining access to your key through disaster scenarios. It’s infeasible to ask someone to remember 32 bytes of arbitrary data even in a mnemonic form. So applications solve this by asking you to write your recovery seed down, print it off, store it in a safe deposit box, etc. Ideally this is a great idea. The problem is nobody does it so in essence it doesn’t count. We need another solution.
Of course some of you do print out your recovery packages, emergency kits, mnemonic seeds, etc. and store them in safe deposit boxes and/or keep copies on hardware wallets. Kudos to you. There are certainly scenarios where this level of attention is a necessary and appropriate response to the modeled threats. We just don’t think that those type of threats are in scope for the everyday internet citizen. Further, we suspect even if you’re securing a crypto fortune from aliens, you still might want an easier to use solution for your everyday credentials.
We considered a lot of things, some clever, most absurd. At one point we contemplated actually printing off your recovery seed for you and mailing it but ultimately concluded the postal system is a hostile environment and realized we have no way to establish an out of band channel with users over which to exchange an ephemeral encryption key that we could use to protect the seed in transit. And of course that would also mean our service would see everybody’s seeds which is... not great. Software shops can, even inadvertently, be hostile environments too. But I digress.
To ultimately figure out an approach, we took a step back and asked, “what do actual people do with things they care about?” Turns out, more often than not, they share custodial responsibility. People give house keys to trusted neighbors and family members. They share important tasks like money management with spouses, accountants, and banks. The average child has two custodial parents. Teams share on-call responsibility for critical infrastructure and doctors for sick patients. People maintain emergency contacts and important assets are designated beneficiaries. The list goes on.
The troupe among tinfoil hat security enthusiasts is that it’s you against the world, trust nobody. But we’re here with the reality check: that’s not actually how society operates. People fundamentally trust others to help them through the most important parts of life, so Uno must embrace this innately human reality and provide tools to allow users to spread the custodial responsibility for their identity across a network of confidants.
Okay, “kum ba yah” that’s great, but the tinfoil hats aren’t strictly wrong. Sometimes good people do bad things. Relationships change and deteriorate. Importantly, while the shift to digital communications has afforded many conveniences, it has also introduced new threat vectors. As your identity becomes increasingly digital so does its exposure to new, non-traditional, threat vectors like scale and social engineering.
Naively, we could build tooling to help you simply give others a copy of your recovery seed and wave our hands and call it a day. But it would be irresponsible to completely ignore the annoyingly digital parts of the problem. Instead, we took a nod from the Web3 community: the solution is to make sure nobody in your network of confidants has access to a full copy of the seed at once. Conceptually it’s like putting 3 locks on your door, choosing 3 friends, and giving each one keys to two of the locks. No single person can unlock your door because nobody has all three keys. But, if you ask any two of them for their spare keys, you’ll end up with a complete set.
I want to note that I’m primarily discussing a generalized baseline replacement for the concept of protecting a digital vault with a password or key that is written down and put in a secure location, bus factor = 1. Some people will have certain confidants who they do trust with full custody of their identity seed. This is fine and in practice we expect we’ll see people choose a mix of a fair number of friends with partial copies of their seed and a few ultimately trusted confidants with full copies of their seed.
It turns out you can set up a digital analog of the 3 lock concept. And while rekeying would be super cumbersome in the physical scenario, technology makes it lightweight and feasible in the digital scenario. Convenient!
Shamir’s Secret Sharing
It’s time to introduce Adi Shamir. You might know him as the S in RSA: Shamir invented a perfect (k,n)-threshold secret sharing scheme called, naturally, Shamir’s Secret Sharing (SSS). The idea is that you break up a secret into n parts such that it can be recovered if any k of them are combined together. The idea of using this scheme to protect recovery seeds is not unique to Uno. There’s a practical formulation of using it to protect BIP-39 mnemonic seeds (the human-encoded form of a crypto wallet key) called SLIP-39. A community with a vested interest in making recovery seed storage more resilient invented the specification. Popular devices like Trezor hardware wallets (among others) support it. These are good indications that we are barking up the right tree.
“Why not multi-sig? I read a thing that argues it’s superior.”
—Your concerned friend
One line we refuse to cross is to make ourselves in any way a custodian of your full key material. In crypto parlance, we’re a non-custodial “wallet”. Being custodial would open us up to all sorts of attacks with grave consequences (like all our users’ credentials becoming compromised at once). And generally we don’t think giving some company complete keys to your digital life is the answer or in the spirit of what a modern identity agent should be. Or maybe we just don’t trust ourselves with that level of responsibility. Either way, like Signal, the only information we want to know about you is that some random public key (maybe linked to a phone number) uses our service to securely store things (although we’ll probably be required to know a tiny bit more about you if you end up paying us for our services, we’d never have access to the things you store). We’re here to help you keep your digital identity independent of central authority access and control—not become the next one.
”You didn’t really respond to the technical gripes in the argument.”
Most arguments against Shamir’s Secret Sharing are that it’s too raw of a primitive and thus people trying to implement it usually screw up. And the logistics are hard and get pushed onto the end users. We use SLIP-39 because it specifies a robust application of SSS to exactly our use case. I don’t think there have been nearly as many gripes about SLIP-39, but, it’s also pretty new. As far as logistics, we’ve solved those with good UX and done the meticulous work on the back end required kept them out of our users’ hair.
Uno uses SLIP-39 as the underlying mechanism to allow users to defensively share custodial responsibility for their identity seed across a network of recovery contacts. Let’s cover the machinery by working through a concrete example. You can follow along by using the Uno CLI.
First, initialize the Uno CLI.
$ uno init
wrote: ~/.uno/config
This grabs 32 bytes of entropy and writes them to a file ~/.uno/identity. This file is private and normally you wouldn't share it with anyone. But since we're walking through an example here, I'll show you:
$ cat ~/.uno/identity | base64
Ww2Grba4Kmde7gmqu4j71qFb5RydIdQYn9pjoXtT+gwYou can encrypt and decrypt data with this seed, sign messages, and interface with the Uno API. For now let’s just split the seed up into some shares. To do this we’ll use the s39 section of the CLI:
$ uno s39
uno-s39
SLIP-0039 Options
USAGE:
uno s39 <SUBCOMMAND>
OPTIONS:
-h, --help Print help information
SUBCOMMANDS:
combine Combine shares of a split seed back into the whole identity seed
help Print this message or the help of the given subcommand(s)
split Split an uno identity seed into a number of shares
view View metadata about a mnemonic share
There’s not a whole lot to choose from. The split subcommand sounds like it will do the trick.
$ uno s39 split -h
uno-s39-split
Split an uno identity seed into a number of shares
USAGE:
uno s39 split [OPTIONS] <SEED>
ARGS:
<SEED> The identity to split
OPTIONS:
-h, --help Print help information
--minimum <num> minimum shares needed to reconstitute the seed [default: 2]
--total <num> total shares generated [default: 3]
Notice the minimum and total options. Those correspond to k and n, respectively. The default 2 of 3 split will work fine for now:
$ uno s39 split
Group 0:
Group ID: 26582
Total Groups: 1
Required Groups: 1
Total Shares: 3
Required Shares: 2
Shares List:
[
smirk prospect academic acid ambition adapt hormone pecan prepare body dictate device harvest prayer pants story making march grant crazy scared alpha party acquire hour editor founder greatest browser lecture evidence auction western,
smirk prospect academic agency actress metric beyond answer public kitchen typical mailman rescue lawsuit memory boundary romantic party deploy system wine regular muscle curious elder airline view blimp river employer body pink wildlife,
smirk prospect academic always antenna theory mortgage mixture detect employer nuclear chemical jacket adjust wrist eclipse facility mustang should salon playoff wrist short diploma club amuse cage trial fiction aluminum secret move angry,
]
Now we have a group of 3 total shares any two of which, when combined, provide enough information to discern the original seed. The shares are presented in their mnemonic form, which is appropriate for handling by humans (machines do just fine with that format too—it’s just not as compact as possible). You can tell the shares are related because the first 3 words (representing 30 bits of share data) of each share are identical. Let’s decode one of them and see what information it contains:
$ uno s39 view 'smirk prospect academic acid ambition adapt hormone pecan prepare body dictate device harvest prayer pants story making march grant crazy scared alpha party acquire hour editor founder greatest browser lecture evidence auction western'`
Share ID: 67d6
Group Index: 0
Group Count: 1
Group Threshold: 1
Share Index: 0
Share Threshold: 2
Share Bytes: [140, 7, 110, 105, 10, 200, 89, 54, 141, 118, 162, 173, 160, 246, 88, 174, 50, 100, 138, 140, 68, 29, 162, 0, 54, 237, 5, 91, 153, 97, 154, 4]
Share Checksum: 0
Importantly, there is enough information available to provide some checks and guidance during share recombination. Imagine if you had a bag of random shares from different splits, it might get confusing. The ID associates related shares and the share threshold tells you how many distinct shares with the same ID you need to recover the group secret. The checksum allows for error detection. These extra bits of information are helpful because you can run the raw SSS algorithm on arbitrary bytes and they will “recombine” into more arbitrary bytes. There’s no explicit indication whether the bytes belonged together in the first place. So SLIP-39 adds these practical niceties.
If you’re following really closely, I’ve glazed over groups altogether. SLIP-39 actually specifies a 2-level strategy where you can require j of m groups each of of k_i of n_i shares with a max of 16 for m and n individually. Our library code supports the full 2-level SLIP-39 spec but our CLI and app pin j and m at 1, which degenerates into a traditional simple k of n split.
🎉 Thankfully users don’t need to worry about any of these details. The app handles all these lower level concerns.
Anyway, let’s try recombining. You can pick any two of the shares. I’ll use the 1st and the 3rd, but you should try with your own selection.
$ uno s39 combine --shares 'smirk prospect academic acid ambition adapt hormone pecan prepare body dictate device harvest prayer pants story making march grant crazy scared alpha party acquire hour editor founder greatest browser lecture evidence auction western' 'smirk prospect academic always antenna theory mortgage mixture detect employer nuclear chemical jacket adjust wrist eclipse facility mustang should salon playoff wrist short diploma club amuse cage trial fiction aluminum secret move angry'`
Ww2Grba4Kmde7gmqu4j71qFb5RydIdQYn9pjoXtT+gw
Voila! That’s our original seed.
Just like that we’ve mathematically split 32 bytes of secret data into 3 shards each containing enough information such that we can discern the original secret when at least any two shards are present at once.
Distribution and Revocation
The Uno CLI is a barebones utility for working with Uno’s domain logic. At the moment, you’ll need the app to facilitate the higher-level trusted contact selection experience as well as the share distribution and managed share rolling features.
Distribution happens using uno’s secure application messaging system. The major benefit of building an application layer PKI is that we can use it to perform sensitive tasks like this without really batting an eye.
Revocation is a little more tricky and no less important. Using a strategy like SLIP-39 is not without its downsides. The primary one is that when there is any change in the group of people to whom you’ve distributed shares, especially if you were to remove someone as a recovery contact, everyone remaining in the group must destroy their current share and accept custody of a new one. Coordinating this across a set of mobile devices is not exactly simple. Regardless, again thanks to our secure messaging system, the main headache is simply making sure to appropriately manage and drive the process through its inherently asynchronous and ad-hoc nature to completion.
A key-shard escrow strategy like this is also susceptible to collusion among your recovery contacts. This is why it’s important to not publicize the list of recovery contacts you’ve chosen. When you elect contacts, do so privately, one on one. Ultimately, though, you need to choose responsible and honest people.
Posture
Your security posture reflects the type of threats you’re worried about as well as the habits you’ve formed. While we are super excited about tackling this problem socially, it’s not the perfect fit for everyone. We support manual recovery seed backup too so regardless of which failure scenarios keep you up at night, we have a solution. And there’s no reason you can’t combine both approaches too.
Summing it up
Instead of passwords, Uno enables users to elect recovery contacts each of which is entrusted with a shard (so to speak) of the users’ identity seed. The process we just went through is the same one the app uses to split and combine shares. In fact, the app even uses the same Rust code. If a user loses all their devices and needs to bootstrap on a new device, they simply launch the app and initiate messages to a few of their recovery contacts. Instead of typing in a password, users select their recovery contacts and the app handles the rest.
Shamir’s Secret Sharing is a really neat concept and we’re taking a shot at introducing SLIP-39 in a social consumer context with a much more targeted user experience than “your crypto wallet supports SLIP-39 figure out what that means and good luck”. We have built infrastructure to handle all the annoying problems surrounding a share escrow strategy such as share creation, secure share exchange and storage, share recombination and the share rolls required when modifying your circle of recovery contacts.
Finally, this is one of the more radical ideas we’re pursuing and, while it’s generally been well received, we’re actively soliciting feedback on our approach. Join our discord and share your thoughts.
