Idea for how to secure my digital assets

Here’s an outline for how this problem could be solved. Note that this is only about “archived”, “backed-up” versions of the data, not production use. E.g. to edit my family pictures, I continue to have them on my PC. And to log into a website, I continue to use a local password manager. This is about making that data recoverable.

The data side of the scheme:

  1. I assign every one of my digital assets to a “bucket”. Think of a bucket as an archive file (like a zip file), or a directory on some file server. It can be very small (e.g. holding a single password) or very large (e.g. all my home videos).
  2. All items in the bucket have the same access controls: I can decide to let you have access to the bucket (for how, see below) and that means you can access everything in that bucket. If I wanted you to not have access to a few items, they need to be assigned to a different bucket.
  3. There can be any number of buckets. In particular, I may decide I want only one to keep things simple.
  4. The bucket is copied to some on-line storage service, or to as many storage services as I like. If I create several copies in different locations, I should be rather certain that not all of them will disappear.
  5. Ideally the on-line copy of the bucket is kept current in an automated fashion. Think Time Machine, but not (only) to a local disk, as that one would presumably die in the same fire.
  6. Obviously, the on-line copy is encrypted. For my scheme, it is encrypted using public key cryptography. The public (encryption) key is stored wherever it needs to be stored so the backup can be automated. Given it’s a public key, there’s no need to keep it secret. Read on for what we do with the private keys.

Here is the people side of the scheme:

  1. Everybody who has any kind of access to anything in this scheme has a personal public key pair. The private key of that pair is never used by anybody else than the owner, and never shared with anybody. It is stored as safely as the owner can.
  2. For my data, the following people might need a key pair: myself, my wife, certain relatives, my lawyer etc.
  3. Everybody sends me a copy of their public key. I store those public keys somewhere convenient, but because they are public keys and can easily be obtained again, I don’t need to secure them.

Here is how the two sides connect:

  1. When I set up a bucket for the first time, I create a public key pair for the bucket as described above. The private key never gets stored in plain text anywhere. Instead, I encrypt it with my own public key and store that.
  2. When I need to access the encrypted bucket, I use my private key to decrypt the bucket’s private key, and then I decrypt the bucket.
  3. The encrypted private key can even be stored with the bucket, so I can be sure I have access to it when I need it. Given it is encrypted, it does not need to be protected very much, although obviously I could do that to further increase security.
  4. Here comes the key part: I also encrypt the bucket’s private key with the public key of the person that I want to have access to the bucket, and make the encrypted key available to them.
  5. I could even encrypt the bucket’s private key with the public key of person A, and the result with the public key of person B. That way, neither A nor B could access the bucket unless they cooperated with each other. This is the equivalent of needing two keys to open the safe.

Here is how it would work:

  • Assume my hard drive crashes or the laptop is stolen. I retrieve the bucket’s encrypted private key, decrypt with my personal private key, and get my data back.
  • Assume I lose my private key. I talk to my wife (or anybody else who has access to the bucket) and have them get the data for me. Depending on the bucket, I might have to talk to different people. I generate a new key pair for myself, and encrypt the bucket’s private keys for myself again. (I got those from my friends who still have access to their private keys.)

What do you think?

 


Posted

in

, , ,

by

Tags: