Blog

tl;dr– A decentralized system to ensure access to your passwords and data in the event of your untimely end. Your master key is split among trusted parties in such a way that any set of them larger than a chosen threshold can reconstruct it.

We store so much of our lives online these days. What would happen to it all if something were to happen to you?

It used to be that when you passed on, your friends and family could go through your personal effects. They’d find photo albums, old correspondence, account statements, address books (and probably a few things you didn’t want them to find, but who cares; you’re dead). Even ten years ago, with the PC revolution well underway, they’d still find hard drives and CD backups. But nowadays, what would they find? Your data is in the cloud, or on a laptop that probably got destroyed in the accident you were in. And if it didn’t, that laptop had full-disk encryption turned on anyway.

It’s a genuine concern that sizable chunk of your data (dare I say you) might simply disappear forever. Who would have access to your accounts? Who would even know about all your accounts?

It’s definitely a concern of mine. I follow strong security practices, and I know for a fact that if I died or became incapacitated, no one close to me would be able to access my accounts or data, end of story. Hell, I could just suffer from straight-up amensia, in which case even I would lose access to my data.

Clearly we need a failsafe plan – a means of granting access that isn’t solely dependent on the continued well-functioning of my brain. But what?

• Give my passwords to a trusted friend?
• Seal them in an envelope in a safe deposit box?
• Use a service dedicated to the task?
• Set up an elaborate treasure hunt like in The Goonies?

But the risk is clear: these are all single points of failure. The friend and I could have a falling out; they could be victim of a theft; the contents of my safe deposit box could pique the interest of a nosy government; the service could get hacked or go out of business; and my subterranean booby traps will fail due to lack of maintenance and water damage. We can’t have all our eggs in one basket.

Instead, what if we had a way to distribute the credentials among multiple trusted parties, where each individual piece alone is useless, but enough of them put together could effect recovery. Enter Shamir’s Secret Sharing Scheme or ssss.

SSSS

ssss allows splitting up a secret into many pieces (or shares), where any subset of them above a certain size (the threshold) is enough to reconstruct the secret. If a set of shares is even one short of the threshold, it offers no more clue to the secret than random gibberish.

As an example let’s produce nine shares:

$ ssss-split -n9 -t4
Generating shares using a (4,9) scheme with dynamic security level.
Enter the secret, at most 128 ASCII characters: Using a 184 bit security level.
1-6f55bc5bf173feea970cba965c29e9b25fb0338e8e5341
2-966dacee66cb473dfd19373f8cad74e343a14322dd860a
3-22308fa7600216b0b8cd8bdf5239103859a4cada44ba92
4-f296355aa3eb21edb2fe098a099a6240a87476bb72369a
5-1869ee11f17bc0932b810983903a955810a07b731134d6
6-5c140ea0ce7018a3f8c3fdf8ced72f8e491203beb69c35
7-c4d04686ed48a9fb25847464967d3360a7ed39102b97be
8-d0a34538bde9eca08a3fa42a23a16a5ddae3bad8d00af1
9-6c4e15159bee2ec4f97d62fa20edaa7e1d8b14855fc77f

Any four of them is enough to retrieve the secret:

$ ssss-combine -t4
Enter 4 shares separated by newlines:
Share [1/4]: 2-966dacee66cb473dfd19373f8cad74e343a14322dd860a
Share [2/4]: 5-1869ee11f17bc0932b810983903a955810a07b731134d6
Share [3/4]: 6-5c140ea0ce7018a3f8c3fdf8ced72f8e491203beb69c35
Share [4/4]: 9-6c4e15159bee2ec4f97d62fa20edaa7e1d8b14855fc77f
Resulting secret: the keys to the kingdom

$ ssss-combine -t4
Enter 4 shares separated by newlines:
Share [1/4]: 1-6f55bc5bf173feea970cba965c29e9b25fb0338e8e5341
Share [2/4]: 6-5c140ea0ce7018a3f8c3fdf8ced72f8e491203beb69c35
Share [3/4]: 8-d0a34538bde9eca08a3fa42a23a16a5ddae3bad8d00af1
Share [4/4]: 3-22308fa7600216b0b8cd8bdf5239103859a4cada44ba92
Resulting secret: the keys to the kingdom

So now we have the tool. How exactly do we use it? There are two main issues to consider:

1. what the secret payload should be
2. how to divide it up and distribute it among trusted people

The Payload

The goal of the secret payload is that with it, someone could unlock your entire digital life. They should be able to do this entirely without your help, and have a reasonable chance of success even at some indefinite point in the future.

At a minimum this means: knowledge of all accounts, usernames, passwords, security questions, encryption keys and passphrases, etc. But in addition to that, they’d also need a clear set of instructions on how to recover everything essentially from scratch.

For example, you’re not going to include every single password for every account you have. It would be completely unmaintainable. What about new accounts you create after you distribute the shares? Or changed passwords? No, you probably need everything in a password vault. So include the master password to that. But how would they get the password vault? You probably have a backup service*. Include the password to that too. What about any 2-factor auth? They’ll need the one-time-use codes for that as well (or at least a means of retrieving them). You’re starting to get the hint… creating the universe from nothing, avoiding chicken-and-egg, yadda yadda.

* I’m reminded of the uneasy moment when I realized my keepass was backed up to my crashplan, and the password to my crashplan was in… my keepass.

The instructions for your recovery plan need to literally work from beyond the grave. What you put in place should be able to work, with no intervention from yourself, potentially 5–10 years down the road. So think through it very carefully. Do a dry run. Don’t depend on undependable things (Google will probably be around in 10 years; that dude’s Hacker News weekend project will not). Identify points of failure and add mitigating steps (for example, including a snapshot backup of your password vault in the payload is probably a good idea).

The Secret

One property of ssss is that the shares must be at least as long as the secret. Your full ‘digital will’ is by this point probably becoming quite long. You don’t want to dump this full content into ssss; the shares would be unwieldy, and take very long to generate.

The secret must be short. You have two options:

• Distribute the ‘will’ in plaintext. Replace each sensitive piece of info with a fill-in-the-blank, and construct the secret as a list of the sensitive info to fill in.

  Pro: shareholders can review the overall instructions a priori and request clarifications

  Con: will not work if your content has many passwords (such as if including a snapshot of your password vault); method strikes me as somehow inelegant

• Encrypt the ‘will’ with a symmetric key and use that key as the secret. Distribute the encrypted payload to some (see Roles below) along with their shares

  $ passgen.py -b128
  vfkn66dtxv2nopheneod0jb64 (length: 25; 129.2b entropy)
  $ gpg -c --armor < my_directives
  Enter passphrase:
  -----BEGIN PGP MESSAGE-----
  Version: GnuPG v1.4.10 (GNU/Linux)
  
  jA0EAwMCU/FDY3Gf3RtgyRyfXSlLrTlYuZWvSeLNi7mdv/E2XrE6Q3Fsbls7
  ...
  

  Pro: you can include traditional ‘will’-like content meant to only be viewed upon the event of your death (or does this only happen in movies?)

The People

The hardest part of the entire process is deciding just who to distribute the shares of your secret among, and what the threshold should be.

The overarching advice I can give is: keep it simple! You can go crazy with fancy arrangements, but it’s best to pick a small, manageable set of shares and people. We’re not trying to maintain return-strike capability in a nuclear attack here. By keeping things simple, you can really think through the reconstruction scenarios and ensure both the security and resiliency of the system.

The people involved fall into two roles: Executors and Shareholders.

Executors are the people you want to gain access if something happens to you. They have access to the payload, and the list of all shareholders. They would be responsible for collecting and combining the various shares, and following the instructions for recovery. They need not be technical, but should know where to find someone (or how to find someone who could find someone) capable of running ssss and doing decryption. Executors are likely also shareholders.

Shareholders simply hold the individual shares of the secret. They don’t have access to the payload it would unlock, nor do they necessarily even know who the other shareholders are. Traits of a good shareholder:

• trustworthy
• dependable – have been in your life for a long time, and likely to remain in your life for a long time
• will take the endeavor seriously; won’t treat their share in a cavalier manner
• organized – not likely to lose the share
• basic digital security competency
• flattered/excited to participate in a scheme that feels like something out of The Bourne Identity.

Choosing Your Shareholders

As a starting point for choosing your shareholders, identify different areas of your life and pick one to a few ideal candidates from each. Examples of these different areas include: your spouse, immediate family, extended family, old friends, professional relationships, etc. Using a diverse set of personal relationships for your shareholders is essential to your security.

Although ssss does not allow for creating ‘partial’ or ‘weighted’ shares, you can simulate it by giving different numbers of shares to different shareholders. The most trusted shareholder may get three unique shares, whereas a peripheral shareholder will only get one. In this case the participation of the most-trusted shareholder will have 3x the weight of the least-trusted. Remember to scale up your threshold accordingly!

In a related vein, you can minimize the potential for conspiracy among shareholders who know each other (i.e., picked from the same social circle) by giving them duplicate or redundant shares. For example, college buddy #1 may get shares A and B. Buddy #2 gets B and C, and buddy #3 A and C. A single buddy can provide two shares, any two buddies three shares, and three or more buddies is no better than two. The simplest case of this is to give each buddy the same share. In effect each buddy becomes a backup shareholder for the other. Only one person’s response is needed in order for the share to ‘count’. Additional responses provide nothing extra. You get extra resiliency with little trade-off of security.

Use these two strategies judiciously. Remember, keep it simple!

Lastly, don’t discount yourself as a shareholder. You can hold shares yourself – securely – but in a manner where they will be available to the executors should the need ever arise, and this will greatly assist with recovery. You could keep them in a safe deposit box (though ensure the contents will be made available to the executors of your will), or use a ‘heartbeat’ service that will automatically disseminate your shares should you fail to check in after a certain amount of time (be mindful of this timeout delay – likely several weeks at least – in your recovery plans). You will obviously be the most trusted shareholder, but don’t make your shares so strong as to undermine the need for your other shareholders’ participation. And definitely don’t store an above-threshold amount of shares in this manner (single point of compromise). The goal is just to provide some tipping-point leverage.

Once you have mapped out your likely shareholders and the share distribution, trace out the possible recovery scenarios. Identify the minimum viable set(s) of people that can reconstruct your secret, and decide if you’re comfortable with that. At the same time, be confident that at least one of those sets will be possible at any time in the future, accounting for potential lost shares, people disappearing off the grid, etc. Especially consider that, depending on how much time you spend together, you and another shareholder may suffer the same misfortune!

Of course this all depends on your chosen threshold. It’s really up to you, but I would favor a threshold on the relatively high end. Account for the possibility of one or two shares being unavailable on the day-that-may-never-come, but hopefully any redundant shares you distributed and your own reserve shares should provide enough safety buffer.

The Grunt Work

Whew. Now onto the process of actually generating and distributing your shares.

Before we get started, let me stress that having all your shares in one place is dangerous! Any time a critical threshold of shares is in the same place, it is enough to compromise all your accounts, so handle with care! In particular:

• keep the shares on secure storage as you work with them (encrypted drive/partition)
• use secure file deletion to remove all traces of the shares once they have been distributed
• never put a share in a place where it can’t be deleted (i.e., be very wary of the cloud)
• be mindful of the many places on your computer where the share contents may be cached (especially if converting to a barcode image):
  • command-line history (just don’t)
  • browser history
  • thumbnails in file manager
  • history in any barcode scanning apps that you use for ‘test’ scans
  • printer queues

Given the minefield of ways to slip up, using a dedicated security-hardened VM seems very prudent.

Once you’ve generated the raw shares, you can take the optional step of encoding them as barcodes. I prefer to do this as it makes them slightly less ‘scary’ to your non-technical shareholders, and easier to work with for distribution, reassembly, and potential hard-copy storage.

To do so:

$ cat | qrencode -i -s8 -o /mnt/encrypted/ssss/shareC.png
3-22308fa7600216b0b8cd8bdf5239103859a4cada44ba92

Run once per share, or per shareholder (with all the shares assigned to that person in a single barcode). Do not enter share contents on the command line unless you’re sure you’ve disabled command line history!

and we get:

…

Next you must notify your chosen shareholders of their new responsibilities and give them their share. The key takeaways they should understand are:

• treat the share with the same secrecy and care as they would their own passwords
• hand it over to an executor when called upon
• try to independently verify that something has happened to you to warrant hand-over before doing so
• don’t lose the share!

Here is a sample email you can send:

Hey, we keep so much of our lives online these days, I realize that if something were to happen to me, nobody would know my passwords and a lot of that stuff might disappear forever. It’s morbid to think about, but best to be prepared.

To that end, I’ve enacted a recovery scheme. Attached to this email is a barcode. It contains encoded info that, when combined with a sufficient number of other barcodes that I’m distributing to other trusted parties, will make my passwords recoverable.

All you have to do right now is keep this email safe. If you’re reading this from a gmail account, just archive the email and it should remain in your account forever. Keep the barcode private until such a time when it may be needed. If you’re ever asked for the barcode, please try to independently verify that something has happened to me before giving it up.

Thanks for being my digital custodian.

Expect to get some jokes the first few times you talk to these people after sending this email.

“Hi, Dad”

“Is this channel secure??”

Actually distributing the shares is another tricky issue. All shares living in your outbox fails the ‘multiple shares in plain view’ criterion. Do it if you’re confident you can truly ‘delete forever’ from your email after you send. Or send different shares from different email providers. Or distribute shares via hard-copy.

Once they’re all distributed, breathe a sigh of relief, then clean up after yourself. Leave no traces of your shares hanging around in the cloud, on disk, or on a mobile device. Do make a backup of the shares you generated, if for no other reason than to replace lost shares, but store them securely, such as in your password vault.

In conclusion

The process we’ve outlined here is cumbersome; it requires much thought and careful typing. But it must be this way; we are creating a diffusion of responsibility, and by definition we cannot rely on any single third party.

In the end I hope you will find it worth the peace of mind… to know that if you were to disappear tomorrow, that your friends and family – in addition to the turmoil of losing you – would not also find themselves suddenly locked out of everything you ever wrote, photographed, archived, and produced.

⁂

There are three deaths.
The first is when the body ceases to function.
The second is when the body is consigned to the grave.
The third is that moment, sometime in the future, when your name is spoken for the last time.

Ensure the longevity of your data!