Do I really need encryption?

[panz]

I agree. At least a simple notification along the lines of "Ensure all keys and metadata are backup as per the manual (Chapter X Section Y)" would go a long way towards making FreeNAS more user-friendly.

Dusan's script to backup GELI metadata is simple: I believe that implementing it in the GUI is not so difficult.

 

[cyberjock]

Microsoft doesn't do the same thing when you go jacking off on the registry. Why would we do different?

Technically @joeschmuck you are correct. What you have with compression is weird.

Your disk contains two partitions, p1 and p2. p1 is swapspace and p2 is a "freebsd-zfs" partition type.

Then, inside the p2 partition is actually a geli device (and not a zpool) and inside the geli device is your zpool. So the partition type is technically correct, but only by random chance. The p2 could easily be set as ext4 AFAIK and nobody would be any wiser.

 

[solarisguy]

manufacturer reading the contents after the drive is RMAed (they will be able to see that it is a ZFSand encrypted)

Is this correct? It's my understanding that the encryption operates at the disk level, and that the filesystem is created on the encrypted device. If that's the case, it would seem that the manufacturer (or recovery company, or anyone else) would not be able to determine what filesystem was in use.

You and cyberjock, who just wrote about it, are correct. For example, the following output from gpart

Code:

[root@freenas ~]# gpart show /dev/da1
=>      34  61457597  da1  GPT  (29G)
        34        94      - free -  (47k)
      128  4194304    1  freebsd-swap  (2.0G)
  4194432  57263199    2  freebsd-zfs  (27G)
 
[root@freenas ~]#

cannot be relied upon. However, when following documentation that is what gets written to the disk.

P.S. If you go with a hex viewer to the end of the disk, you can see

Code:

GEOM::ELI

That is a hint that the encryption is being used.

 

[panz]

Encryption is ALWAYS used, because swap space is ALWAYS encrypted ;) even if you didn't choose encryption for your pool.

 

[solarisguy]

Yes, FreeNAS swap is always using encryption. But that is not coming into play here.

To verify, please create a ZFS pool on a disk (2GB USB device is enough) without a swap, then compare the end of the disk when ZFS pool is created with encryption and when pool is non-encrypted. Then the same with a swap partition. The information at the end of the disk describes ZFS pool partition.

I have no idea about ZFS, EFI, GEOM, ELI etc. internals, I have only noticed that there is a definite correlation.

 

[erturne]

There are many pitfalls. Here's the one's I'm aware of:

1. GELI metadata is not included in the config file and there is no option to backup or restore the GELI data from the CLI. *THIS IS A SINGLE POINT OF FAILURE FOR A DISK IN AN ENCRYPTED POOL* If that one sector is either corrupted or becomes unreadable you cannot mount that disk, period.

Is there a manual workaround for this? I'm changing my NAS to use encryption.

 

[Fox]

Is there a manual workaround for this? I'm changing my NAS to use encryption.

See this thread... Dusan has some code to do the backup. Be sure to read all of it, I think the initial cut and paste didn't go well and there was an error with the quote character IIRC..

http://forums.freenas.org/index.php...gle-freenas-primary-storage.17316/#post-93073

 

[9C1 Newbee]

I am so glad I didn't choose to use encryption. I knew it could potentially be a can of worms. As been mentioned, my primary concern is when you RMA drives. I assumed I was a bit (pardon the pun) safer than most due to the not so widely familiar ZFS file system strung across an array of 6 disks. With a pallet of RMA drives, I seriously doubt we are low hanging fruit and would soon be passed over. Unless I am specifically targeted, I am reasonably sure my porn.....er.......um.....financial information is pretty secure. Or at least that is what I assume.

 

[panz]

I've just destroyed my encrypted pools and started from scratch with unencrypted pools. Less things = better reliability.

 

[9C1 Newbee]

For that reason I too am reluctant to use compression.

 

[erturne]

I've just destroyed my encrypted pools and started from scratch with unencrypted pools. Less things = better reliability.

We've had a couple of break-ins in my neighborhood, so I worry about someone walking off with my server. I just destroyed my unencrypted pool and started from scratch with encrypted pools.

 

[panz]

Good luck ;) After I discovered that nobody didn't care about GELI metadata I started sweating...

 

[erturne]

Good luck ;) After I discovered that nobody didn't care about GELI metadata I started sweating...

The developers are targeting to have something in 9.3-RELEASE according to https://bugs.freenas.org/issues/2375. Until then I'll work around it. Between break-ins in my neighborhood, having my identity stolen earlier this year, and the fact that I've gone mostly paperless at home (i.e. everything is on my NAS including bank information, accounts, etc) the effort is worth it to me to use encryption.

 

[panz]

Bank account credentials should be kept into something like LastPass or KeePass or a Truecrypt container.

 

[erturne]

Bank account credentials should be kept into something like LastPass or KeePass or a Truecrypt container.

I don't store credentials anywhere (those are stored in my brain only), but things like scanned bank statements, credit card statements, mortgage statements, taxes, a copy of my license, copy of my passport, work documents, security paperwork, etc.

 

[panz]

I think that the policy has to be the opposite: credentials that your brain can remember are not safe: for example, I use only passwords that are 50 characters or more in length. My brain has not enough entropy to generate a good password, nor enough "power" to remember it (and all its changes every 3 months), so a software like LastPass or KeePass or 1Password will do all (and better) instead of my brain ;)

 

[Ericloewe]

I think that the policy has to be the opposite: credentials that your brain can remember are not safe: for example, I use only passwords that are 50 characters or more in length. My brain has not enough entropy to generate a good password, nor enough "power" to remember it (and all its changes every 3 months), so a software like LastPass or KeePass or 1Password will do all (and better) instead of my brain ;)

And I thought having KeePass generate 24-character passwords for forums was paranoid overkill...

 

[cyberjock]

Things such as yubikeys can be handy if you want that kind of protection. ;)


http://www.yubico.com/products/yubikey-hardware/yubikey/

 

[9C1 Newbee]

And I thought having KeePass generate 24-character passwords for forums was paranoid overkill...

Not if you're married.

 

[DaPlumber]

These are the personal opinions of a professional systems architect who has worked with ZFS almost since its inception and under Solaris, OpenSolaris, OpenIndiana, FreeBSD, and FUSE (Linux, OS X). I'll stop credentialing now, since it won't make a difference anyway.

One of the design goals for ZFS was to abstract as much functionality away from the low level as possible. Consequently the way encryption is handled in Solaris 11 (and onwards) adheres to this philosophy since essentially encryption is managed as a "plug in" much the same way as compression and de-duplication. The devil-containing details are in the key management, as always with anything crypto-related. If you want to see how easy it is look here: http://www.oracle.com/technetwork/articles/servers-storage-admin/manage-zfs-encryption-1715034.html

Unfortunately with the Oracle purchase of Sun that work did not make it to Open Source before Oracle slammed the door. Until such time as the work is re-done for zfs 5000 or btrfs reaches maturity and functional parity, we're stuck with the current work-arounds.

FreeNAS does not adhere to the ZFS architecture for cryptography but rather interposes a virtualization layer between the raw disk blocks and what zfs thinks are disk blocks. In theory this is transparent. In practice you're lying to ZFS just as badly as if you were using hardware RAID and adding a risk to the zpool integrity that is on a par with not using ECC memory. (Again, personal opinion, others will disagree.)

This does not mean that I am anti-cryptography. Far from it, I'm a firm believer that data at rest should be encrypted AND compressed by default because CPU cycles are cheap if you don't encrypt everything if you do have sensitive data that is encrypted you might as well label it "My valuable and/or incriminating stuff". So my (again personal) opinion is that you should encrypt at the file level or if you must have an encrypted filesystem have your client OS encrypt either a ZFS volume or something like a sparse file. In addition this will ensure the data is also encrypted in transit over the network from client to FreeNAS and FreeNAS is absolved from key management.

Wether you actually need encryption or not is a trickier question and a lot more personal. However I'd raise the issue of "rubber hose decryption", ably illustrated by xkcd:

The rubber-hose-wielders can be the usual three-letter agency suspects, thugs hired by the Ex, etc.

Basically the principle is that you really only need good enough encryption to the point that it's easier/simpler/cheaper for a "bad actor" to switch to "rubber hose" decryption. Beyond that I suggest looking into steganography and dual partitions with dummy lures that can be sacrificed under duress. e.g. a lesser offense (preferably embarrassing) is exposed by one pass key, the much more serious offense data is unlocked with a different key and looks like noise in the empty space until unlocked. If you're in that level of situation on a regular basis I wish you and your kneecaps the best of luck.

tl;dr: Current FreeNAS GELI encryption is a Bad Idea IMO. Do it a different way.:p