Best Practices for Storing Sensitive Documents

[godsfshrmn]

I am trying to figure out the best way to digitally store my family's important documents securely. I have some sensitive stuff that is ripe for identity theft. Right now, I'm using an encrypted bitlocker file and mounting it whenever I need to access or store something. I was thinking earlier that I could maybe achieve this with an encrypted volume and make life easier. I recently purchased a ScanSnap and want to be able to scan to a PDF and send to an encrypted volume by just placing it in the scanner and pressing scan. I have a few questions about doing this though-

1. An encrypted volume that is shared to my desktop is always 'available', rather than the as-needed method of mounting / decrypting / storing documents / unmounting volume with bitlocker VHD's. I believe this is a bit less secure. If my PC was compromised, obviously the data could be accessed. Alternatively I suppose I could create a CIFS share with permissions and not save the password so it prompts each time.

2. Backups - right now my bitlocker files are being sent to crashplan. If I use an encrypted volume, will my files be sent in unencrypted format?

I know the most secure method is 'off-air' with a USB HD or stick, but that is too laborious for me.

How do you manage your documents securely?

 

[Ericloewe]

Encrypted pools have a number of important catches that make it generally better to stick to encrypted containers unless you're legally obliged to encrypt everything wholesale, to prevent against physical theft.

Data sent elsewhere will not be encrypted. For this kind of approach, you'd have to use a container.

 

[DrKK]

I'll tell you what I do for this situation.

I have a couple of TrueCrypt volumes that I store on the NAS. If I need to access them, I mount them and enter the password. VeraCrypt is a popular current iteration of TrueCrypt. You might want to look at that.

A lot of us strongly recommend against a full pool encryption for a number of reasons. In short, the risk-reward ratio is disadvantageous for 99% of people, in many of our views. I certainly suggest that you create a TrueCrypt folder(s) on the NAS, in some dataset that you have set aside for that purpose (disable compression, disable atime, etc), and that you share them out (with CIFS or whatever), mount them into TrueCrypt (or VeraCrypt) and use them that way. An adversary has no reasonable way of getting at your files, and you don't risk your entire pool should something go wrong.

 

[Adrastos]

Do you mind providing a little more detail about what is the downside of encrypting a ZFS pool. I have setup a zfs pool and enabled encryption when it was created. I have also created a security key and a recovery key and stored them away in a safe place. If someone were to take the NAS they would not be able to remount the drives and get to the data without also having the keys. I then would replace the NAS and restore from backup or replications.

I understand the use of using a truecrypt volume and mounting and unmounting. However, encrypting the entire pool and using permissions to control daily access. Remembering that if the NAS is rebooted or drives removed, access to the data is controlled by the putting in the key.

 

[DrKK]

Well, the problem is mostly this: If something happens to your encrypted pool, every single file on it is toast. All of your files, including the ones for which protection by encryption is neither indicated nor necessary, are subjected to the risk of catastrophic loss. What catastrophic loss you ask? Well, when your pool is encrypted, certain types of things can be done in the wrong order, you can zig instead of zag, basically, any kind of innocent misreading of certain documentation for accomplishing certain tasks can cause the whole pool to be hosed. We just had a guy the other week---he, like you, had recovery keys somewhere safe, etc., etc., etc., but he did some kind of advanced ZFS voodoo to his drives, and rebooted in the middle of the process when he shouldn't have...and he lost his pool, because it was encrypted. His recovery key didn't help him then. In short, unless you're a voodoo master, you cannot predict exactly how the fact that you are using encrypted devices will cause counterintuitive dependencies and risks.

There is also a very slight, to moderate, impact on performance (depending on CPU, AES-NI, etc.) when using encryption, but these days, with i3 or better CPU's, this is not a big deal.

In short, it induces a global risk to the whole pool. The pool has all of the risks concomitant with using an storage array on ZFS, *PLUS*, it has the additional risks of using eli devices to populate your vdevs. The main argument against encryption is that there is palpable risk of loss that it induces unless you do everything perfectly correctly (and in the past 18 months, we have had a LARGE NUMBER of people that THOUGHT they were doing everything correctly, and now cannot decrypt their pools), coupled with the fact that the vast majority of the data someone is putting on their pool (media, etc) does not require encryption protection. Whole-pool geli encryption offers a risk profile to your pool, while only paying the typical NAS consumer a very small dividend. The risk-reward is not in balance.

Normally people only need a small percentage of files protected. Financial files, videos of their girlfriend's vagina, etc. For this small percentage of files, no additional risk profile is induced when you simply use an encrypted container format, in the TrueCrypt vein. And that is certainly what I suggest.

If someone is sophisticated enough to mount ZFS pools they have stolen, they're probably also sophisticated enough to pwn your hardware in other ways. If you have to RMA a drive, you can overwrite it with zeros.

 

[Adrastos]

Thanks for the explanation. Certainly worth considering during every deployment. Also, speaks volumes to the value of a solid backup. Thanks.

 

[diedrichg]

So the best practice would be to implement a TrueCrypt or similar container. Can this container live in a dataset with other folders? Should a dedicated dataset be created for each TrueCrypt folder (e.g. dataset1: Tax Documents, dataset2: Emily's vagina, etc) or is okay to create one dataset for all the containers to reside?

 

[Ericloewe]

They're regular files, so you can store them wherever it makes sense for you.

 

[DrKK]

Right. It seems to make sense to me to have a separate dataset. You can turn off compression (which you should for a truecrypt folders), and atime (which is moot for truecrypt folders), etc., etc., etc. But really it doesn't matter too much.

Also, full disclosure: Veracrypt is currently what the cool kids are using in lieu of Truecrypt. It is based on the Truecrypt codebase, but incorporates more sophisticated hashing.

 

[DrKK]

And also, to address diedrich's question, I myself have a couple of truecrypt containers. I have separate ones for:

• Firefox profile
• Thunderbird profile
• Tax forms
• Other financial documents
• Passwords

You run Truecrypt (or, Veracrypt) containers, with strong passwords (i.e., don't use dictionary words, something like "BallsCyberj0cksm0mizza*whore*6969") and you're pretty much going to be safe from any conceivable attacker, except for one with a keylogger on your box.