Storing other's important documents securely

Operating Systems & Open Source Linux
1

My friends and I are looking into storing each other’s very important documents and having distributed infrastructure for resiliency. For instance I store my vault which contains an encrypted copy of my passwords vault, medical records, digital birth certificate, etc. This is then zfs replicated via TrueNAS over a site-to-site VPN to a identical machine at my parents house.

I was inspired by a talk to increase preparedness with my closest circle of friend in the event something happens to one of us. Could be as simple as one of our houses catch on fire and losing everything. We could then access our info off of other people’s servers. This wouldn’t be much data (a few GB at most, all pdf/txt really) but not allowing the person that’s hosting to have direct access would be neat. Would I just have to look at turning some old PC’s into small TrueNAS servers and setting up all my friends’ places? (We are all generally tech savy)

On the other side of this, and I’m not sure where to ask this. I want to look at having shared access to the data in emergencies. Let’s say something was to happen and my spouse medically and my parents need access to records or info. They could go to my friends and say we need access to X. If enough of them say yes then they could use Shamir’s Secret Sharing to access my vault and get into it. There is also the side of while I am trusting my friends enough that this would work. In the event someone is no longer in this group or passes we can revoke/delete their vault/access. Maybe having a master account that requires SSS to get into? I would be interested to know if anyone knows of applications using SSS.

This is something I want to look into and see how it would look and find security concerns from outside viewers before implementing.

1 Like
2

HexOS has the exact functionality you describe. But it’s a paid service (IIRC only once).

3

I tried looking a bit but couldn’t find it. What service/feature are you referring to? I’d be interested in seeing it.

4

A few thoughts in dot point form:

  • “Everything should be made as simple as possible, but not simpler”
  • A simple scheme might be: family knows password, friend stores backups, now they have to cooperate to recover the backups
  • If you only need to split a password amongst 2, create a double length one and give each person half
  • There’s a reason threshold secret sharing schemes are rarely seen in the wild
  • Asymmetric key management is inherently challenging (just ask TLS :D)
  • Paper is a very reliable storage medium
  • Write instructions assuming everyone forgot everything
  • A ZFS stream is a relatively complicated backup transport
  • I like restic going to sftp://|s3://. But borg is cool too. So is tar.
  • Regular test restores are important, but roping in other people to do them is going to be very hard (further making point 1 important)
2 Likes
5

The easiest way to do offsite backup is restic or Duplicati with client-side encryption. The cloud is actually best for this as its redundancy is supreme. If you do 3-2-1 backup you’ll always have multiple local copies of your data anyway.

6

For the hosts having no access to the data, replicate the encrypted datasets raw with zfs send -w. The copy at each house stays locked, and the key never has to be on that machine.

For Shamir’s Secret Sharing, the ssss package in Debian and Ubuntu has ssss-split and ssss-combine. Split the vault’s master password rather than the vault file, for example 3 of 5:

ssss-split -t 3 -n 5

Shares can’t be revoked once they’re handed out. When someone leaves, change the vault’s master password and split the new one into fresh shares for everyone who remains.

Older snapshots and replicas of the vault still open with the old password and the old shares, so destroy the snapshots that hold it after the change.

Drafted with AI.

7

VeraCrypt containers, categorized by the scope of data access.

Imagine you have an accident and end up unconscious in a hospital a loved one might need a specific file, such as xyz.pdf. In this scenario, they should only need to access the xyz.hc container containing that file rather than having to access all.
Each container is encrypted using a key file, which you provide to your loved ones so they can decrypt the specific container and access the required file.

Distribute the containers via a simple web server protected by a password(and fw per ip), perhaps using a domain and subdomains as mirrors.
Give your family a laminated sheet of paper containing instructions, along with a USB pen or SD card that holds the necessary key file.
In an emergency, they should visit the provided URLs in the specified order if one is unresponsive, they move on to the next, and so on. Once the webpage loads, they enter their login credentials, download the relevant xyz.hc container, and mount it using the key file from the USB pen or SD card.

Data synchronization between your devices can be handled however you prefer even a rsync will suffice.

KISS…

Personally, I would advise against relying on highly specialized software, services, or platforms especially those that are heavily centralized, where the failure of a single component could cause the entire model to collapse.

VeraCrypt is relatively popular. Furthermore, you can keep local backups of all its versions, ensuring you’re covered even if it were to disappear from the internet. Its containers can be mounted across various operating systems, and there are also alternatives available for Android.

Access your data via a standard web server there are several options to choose from, and it is highly unlikely that all of them would vanish simultaneously. Avoid building complex instead, use a built in index. This approach also offers complete flexibility regarding your choice of operating system or even CPU architecture.

Keep a physical copy (or several) of your instructions. In a crisis, a hard copy is far more reliable than trying to locate a text file somewhere.

Using a key file stored on a physical medium is more effective than relying solely on passwords. While the web server itself doesn’t necessarily require extreme login-security, the containers must be heavily protected. This allows you to use a simpler password for the web interface one that is easy to type out manually while using a key file for the containers, sparing you the hassle of entering an absurdly complex password, which would be particularly burdensome during a crisis.

The End.

8

Syncthing is a decentralized system similar to dropbox. has “untrusted” shares too, where you can share a folder with a known node and put on a password. The node will receive and store encrypted files.

Otherwise you can just use password protected archives (7zip or whatever) and share them with syncthing.

Access revocation is kinda possible with syncthing, every node can revocate access to another to its shared folder, but the data is not deleted.

Since i assume this is meant to be used by normie friends and family, there is a hard cap on the system complexity before it becomes too complicated for them to operate.

You might be a top level NSA agent but your family members wont handle something much more complex than an encrypted archive with a password