Do I really need encryption?

[solarisguy]

The bad guys would steal the entire server and not just drives, the encryption would not help.

However, from the legal point of view you would be covered. So yes, in your case encryption should be used.

 

[Fox]

For me encryption is just piece of mind for all of the reasons stated above (RMA drive, theft of NAS, retirement of old drives, etc.).

I doubt you would ever have a problem with data theft if you didn't encrypt, but I know I won't have a problem if I do encrypt.

Of course the tradeoff is that encryption complicates things more, and you probably risk a higher possibility of loosing data if you have some sort of system failure, but that is what backups are for!

 

[panz]

The bad guys would steal the entire server and not just drives, the encryption would not help.

However, from the legal point of view you would be covered. So yes, in your case encryption should be used.

If the bad guys steal the server, encryption is absolutely helpful, because they can't access my data!

 

[solarisguy]

@Fox, encryption is seldom a piece of mind.

Nobody who wants to steal your data steals bare hard drives. They bribe the operator, cleaners or just arrange a lover for the system administrator...

 

[Fox]

@Fox, encryption is seldom a piece of mind.

Nobody who wants to steal your data steals bare hard drives. They bribe the operator, cleaners or just arrange a lover for the system administrator...

haha.. not at my house.. Ya, we all know anything can be gotten, I just wanna make it tough.

 

[cyberjock]

In many countries encryption is required by law for medical records and often financial records.

 

[cyberjock]

The bad guys would steal the entire server and not just drives, the encryption would not help.

However, from the legal point of view you would be covered. So yes, in your case encryption should be used.

Why not? I can't mount my drives with out the encryption key...

 

[panz]

In many countries encryption is required by law for medical records and often financial records.

Here in Italy the Law tells you that you have to setup all the countermeasures to stop anyone to steal the sensitive data you're holding, but they don't tell you HOW :)

So, I guess, encryption is the best way to accomplish that ;)

 

[cyberjock]

That's because you didn't download the keys. FreeNAS keeps the keys on the USB stick if you can't be "bothered" to download them from the WebGUI like a good user should. If you aren't downloading the keys and your USB stick fails you'll lose access to your data forever since you don't have the key.

Yes, this has killed many people's data since they didn't follow the manual.

 

[panz]

Moreover, everyone using encryption with FreeNAS should backup GELI metadata

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

 

[joeschmuck]

I have not used encryption but maybe I should play with it in a VM just to see how it works and find any pitfalls. I have not read the manual about encryption either but I'd hope it contains all the information needed to recover should you have a MB failure and need to move your hard drives to another platform. and possibly a new boot USB Flash drive. It would be nice to have a single button action to place a copy of your keys and any other needed data into a directory or single text file, however it works. Yea, I'll read up on it and play with it.

 

[cyberjock]

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.
2. If you don't read and follow the manual for backing up your keys and passwords you may not realize how bad things are until you realize you didn't backup your keys/passwords.
3. If you don't follow the manual for replacing a failed disk you may not realize the actual condition of your pool until its too late. In particular you must rekey a pool after replacing a disk in an encrypted pool. Rekeying only takes like 10 seconds, but too many people don't follow the manual and also don't understand the mechanisms in play behind the scenes. So they learn the hard way when they reboot their server months/years later and find out they can't decrypt that disk because it's key doesn't match the other disks and your resilvered disk is now UNAVAIL again. Had one or two people not realize this snafu until they resilvered more disks then they had as redundancy and rebooted to find their pool was permanently inaccessible.

 

[joeschmuck]

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.
2. If you don't read and follow the manual for backing up your keys and passwords you may not realize how bad things are until you realize you didn't backup your keys/passwords.
3. If you don't follow the manual for replacing a failed disk you may not realize the actual condition of your pool until its too late. In particular you must rekey a pool after replacing a disk in an encrypted pool. Rekeying only takes like 10 seconds, but too many people don't follow the manual and also don't understand the mechanisms in play behind the scenes. So they learn the hard way when they reboot their server months/years later and find out they can't decrypt that disk because it's key doesn't match the other disks and your resilvered disk is now UNAVAIL again. Had one or two people not realize this snafu until they resilvered more disks then they had as redundancy and rebooted to find their pool was permanently inaccessible.

Those are terrible pitfalls!

 

[cyberjock]

They can be.

I actually asked about the GELI metadata when 8.3.0 came out (that's when encryption was introduced). Someone at iX told me it was in the config file, but it's actually not.

#1 has been a thorn in my side for a year... https://bugs.freenas.org/issues/2375

#2 sucks if you don't actually use the manual. I classify this as "user error" in my opinion and not something that needs fixing.

#3 is something that one of the programmers did on purpose. In my opinion this is a bad idea because it makes someone that creates a pool and reboots to see if he has all the required info (keys/passwords) complacent. It gives him the impression that FreeNAS stores the info in the config file (which it doesn't) and later if his boot device fails he's screwed. Personally a ticket should be submited on this one and the argument should be made, but I'm not good at pitching improvements in the past so I figured I shouldn't be the one to fight it.

Note that if you are actually doing what you are supposed to be doing and keeping backups this *shouldn't* be a problem. But, at the same time I don't think that these kinds of risks should be allowed to exist. The user isn't going to know about them and may find out the hard way (and some have).

 

[solarisguy]

Encryption does protect against:

• hard drive theft (as far as we know, nobody today would be able to decrypt it)
• manufacturer reading the contents after the drive is RMAed (they will be able to see that it is a ZFS and encrypted)
• disk recovery company reading the contents, while doing hard drive recovery (they would be able to perform the drive recovery and see that it is ZFS and encrypted)

Encryption will not protect against:

• somebody taking the entire server (unless you additionally set a passphrase on the key)
• somebody using a client system to read the files (for example Snowden)

P.S.
I have removed my earlier post since the information there, although correct, was too incomplete

 

[panz]

I made my choice: when 9.2.1.6 Release will be ready, I'll go to a main pool + a backup pool both of them NOT encrypted :) (after last webex meeting with the developers I discovered that, for an unknown reason, my backup pool doesn't mount anymore, so it's still accessible to replication but not to "ls" or "diff" or "cp" commands, making the pool practically unusable for an easy recovery).

 

[danb35]

manufacturer reading the contents after the drive is RMAed (they will be able to see that it is a ZFS and 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.

 

[joeschmuck]

From the manual:

Once the volume is created, it is extremely important to set a passphrase on the key, make a backup of the key, and create a recovery key. Without these, it is impossible to re-import the disks at a later time.

In my opinion, with respect to the pitfalls, iX Systems should take the approach of an idiot is creating an encrypted drive and push through every single step which must be taken in order to completely setup an encrypted volume and save off the keys, meta data, recovery key, etc... And with appropriate warnings injected as well in case they decide to not perform some portion of the procedure. It should never be left up to how well a person reads a manual, not for this critical of an issue. Although I do agree, the user should be familiar with the manual.

 

[panz]

They should copy from the Truecrypt wizard: it asks you to insert a blank CD or USB; then the software copies there all the needed data to recover even the worst situation. Moreover, the Truecrypt wizard, then, asks you to test the CD recovery system: it reboots the computer, do a self-test and, if all is ok, starts with definitive disk encryption. We'll done!!!

 

[Ericloewe]

From the manual:

In my opinion, with respect to the pitfalls, iX Systems should take the approach of an idiot is creating an encrypted drive and push through every single step which must be taken in order to completely setup an encrypted volume and save off the keys, meta data, recovery key, etc... And with appropriate warnings injected as well in case they decide to not perform some portion of the procedure. It should never be left up to how well a person reads a manual, not for this critical of an issue. Although I do agree, the user should be familiar with the manual.

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