Recommendation for geli based encryption and caveats

Status
Not open for further replies.

FreeNAS_DIY

Cadet
Joined
Jul 20, 2014
Messages
6
Hello!

I am new to this forum so I hope this might be a appropiate place for my post.

At the moment I have a FreeNas testsystem running (9.2.1.6) and I am wondering about the proper use of geli for pool encryption.

My setup is an Asus P9D-X, 8GB ECC-RAM, i3-4130, 6x 3TB WD Red,Raid Z2, booting from a Transcend JetFlash 600, 8GB USB2.0 Flash Drive.
(To be honest the whole system boots only every second time successfully, although all USB3.0 functions are disabled. But this is different problem, perhaps for a different thread ;))

Later on the NAS will serve as a backup medium for all kind of personal data. That means that the NAS is only switched on for short periods of time, namely while data is transfered to or from the NAS. A manual backup of the NAS will be performed on an external USB drive on an regular basis, too.

The testsystem runs already Geli encryption and so far I have no problems with it.
But during my "study phase" before building the NAS I read some posting here which contained some kind of warning using Geli/FreeNAS encryption. As I would like to protect my NAS against data abuse after theft, I want to definitely use some kind of encryption.

So what are the caveats I have to care about if I use Geli for encryption?

I already have saved the metadata of every disk using the command found in this thread and script: http://forums.freenas.org/index.php...ks-from-single-freenas-primary-storage.17316/
Code:
geli backup $disk `camcontrol identify ${disk%p2} | grep serial | tr -s \  | cut -d \  -f 3-`.eli


Regrettably I wasn't able to get the complete script running, so I did a backup manually using this command for every disk.
The script elifun-0.3 found in the same thread at page 2 didn't work either for me. To be honest I have to admit that I am new to the UNIX stuff in general and especially to the scripting language. :oops:

If I am correct, then in case of a failure, i.e. the block wich contains the geli metadata is damaged, I only have to mount an USB flash drive, restore the saved metadata to all the disks and everything should be fine. Or am I wrong?

Are there any other problems related to Geli which can cause a complete data loss of the whole pool in a single (or double) point of failure situation? Or do I have to save further configuration data, additional key-data or something else on an external flash drive to prevent data loss due to damaged encryption?

Is using a huge Truecrypt container the better alternative, although Truecrypt seems to be officially dead at the moment? I assume using a single 10TB file or even two 5TB files may also not problem free. Does anyone have experiences with this kind of configuration?

Please keep in mind that the NAS is build for the porpuse to be a rocksolid, diskfailure proofed backup medium. That is why I am using RaidZ2. The data should be safe by any means! (Of course only as far as RaidZ2 and ZFS allows, but I don't want to introduce am additional point of failure which renders the safety thoughts useless and which introduces new weak points to the system.)

Thanks for your opinions and recommendations.

Kind regards from a FreeNAS beginner!
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
So I'm not using 9.2.1.x so there may be unknown bugs with the encryption. Not many people choose to use encryption and I did it just to see how good/bad it was. It works well, but there's been some.. shall we say... problems.. with encryption in the past.

Now, ignoring any "unknown" bugs, you hit the potentially serious loophole with encryption- geli metadata. If you have backups of your metadata that's always good.

The only other serious "risk" (if you want to call it that) is doing disk replacement or expanding a pool by adding a vdev without rekeying the pool (and backing up your geli metadata again for safe keeping).

Using Truecrypt has its own limitations as it is being remotely stored. Not always the best because there's the possibility of things going wrong through the network. I know a few people that do it, and if your FreeNAS box is reliable (and you do backups like a good boy) then it's relatively low risk.

If I had to choose between Truecrypt and FreeNAS' implementation I'd probably go with FreeNAS' implementation. But that's just me and I'm evaluating the risk of data loss between the two and not how hackable it is. For all I know FreeNAS' implementation is horribly unsafe and easily crackable by some government agency. But for the casual criminal they don't have much of a chance of figuring out what is on your pool, assuming they are even capable of figuring out why Windows' GUI won't come up when they turn on your server. ;)
 

FreeNAS_DIY

Cadet
Joined
Jul 20, 2014
Messages
6
Thank you for your answer, Cyberjock!

The only other serious "risk" (if you want to call it that) is doing disk replacement or expanding a pool by adding a vdev without rekeying the pool (and backing up your geli metadata again for safe keeping).

I don't have any plans to expand the existing pool, so this risk is fine for me. A disk replacement is also not planned, :) but in the long run I am afraid it can't be avoided.
But until now after reading the manual/wiki page I was convinced that a disk replacement isn't really a big thing. Even less if a backup of the geli metadata is existent and can be restored.

What is the potential danger in changing encrypted disks?

Using Truecrypt has its own limitations as it is being remotely stored. Not always the best because there's the possibility of things going wrong through the network.
What do you mean with the last sentence? Do you mean that due to an error or network failure the unencrypted transfered data may become corrupted and therefore a corrupted file is stored in the Truecrypt container file? Or do you mean due to some network error the whole Truecrypt file can be corrupted and all data might be lost?

As far as I know TrueCrypt files are to some extend resistant against damaged blocks and bit rod. That means, that only the affected files within the container are damaged and possibly lost, but not the whole container. At least that is my understanding after some web research (which might be completly wrong, of course).

For all I know FreeNAS' implementation is horribly unsafe and easily crackable by some government agency.
Very interesting. I thought that the FreeNAS implentation bases on AES so it seems to be very safe on the first look. If it is only crackable by legal forces than it is okay for me, but if a normal guy using a one-click tool found in the internet can access my data, than that would be a nightmare! Where can I found further information about the unsafe implementation?

Speaking of "unsafe", a very excellent post of Dusan comes to my mind (http://forums.freenas.org/index.php?threads/recover-encryption-key.16593/#post-85497), which shows in my opinion a small flaw: If one can obtain the recovery key, one can access all the data without typing in any passphrase. So for the sake of security it would be better not to generate a recovery key. Of course it is recommended to generate such recovery key in the manual, and so I did. :D
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
The danger with rekeying your pool is if you don't save your keys and reboot... game over. Your pool is gone forever. We've had a few people do this too. The manual tells you what to do, so unless you decide you are better than the manual it won't be a problem.

As for TrueNAS over the network I'm talking about theoretical data loss due to data that is "in transit" from your desktop to the pool for whatever reason. Kernel panic or anything like that could cause corruption.

If you want to know how "safe" or unsafe the implementation you just need to get educated on geli to the extreme.. give you a few months to understand all of that, then check out the source code for FreeNAS on github.

The recovery key is a risk, but no more risky than getting the key + password. In both cases you should be keeping that stuff under lock and key you should be okay. Besides, even if the USB stick with the recovery key was stolen by some neighborhood thug, do you think they're going to be able to figure out what they are looking at? I'd wager not.
 

DrKK

FreeNAS Generalissimo
Joined
Oct 15, 2013
Messages
3,630
So I'll tell you what I do, as another option.

Almost everything on my FreeNAS is media (I think that's true for most of us). So, there is no security risk, and thus I have no reason to risk encrypting the whole pool, and the headaches that could happen as a result. However, I do want to protext my firefox profile, my Thunderbird profile, my passwords file, the various porn I have of Cyberjock's female relatives, things like this.

What I do in this case: I keep a TrueCrypt virtual folder for that, which is stored on the NAS, under my Owncloud install in a jail.

So, basically, I encrypt only what needs to be encrypted, and I do outside of the FreeNAS context itself (even though FreeNAS is storing the Truecrypt container itself, of course). Best part--I can take it with me when I travel, too.
 

FreeNAS_DIY

Cadet
Joined
Jul 20, 2014
Messages
6
Hello!

If you want to know how "safe" or unsafe the implementation you just need to get educated on geli to the extreme.. give you a few months to understand all of that, then check out the source code for FreeNAS on github.
Hmm, I don't want to dig that deep. :)
As you spoke about an unsafe implementation, my hope was that you perhaps could reveal more information and details about weak points and flaws in it.

A first conclusion after these postings is, that it is safe to use geli if the following points are considered:
  1. Backup the recovery key and the metadata, keep the passphrase safe. To backup the metadata it is sufficient to use at least the geli backup command (see post #1).
  2. Don't fiddle with the pool, i.e. expand your pool etc.
  3. If a disk exchange is necessary than follow exactly the manual. The manual is right. :)
  4. No further FreeNAS system data backups or precaution actions have to be taken to assure a succesful restore after a disk, FreeNAS system and/or geli metadata failure.
Using TrueCrypt can be an alternative if only a small part needs to be encrypted. To encrypt all 10TB in a single container seems not to be a good idea. Although that seems to be based more on the windchill factor as on the measured temperature.

Am I right with my summary or do I miss important points?
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
Sorry, not even going to go there. It's one of those things I don't feel I can even talk about as an authority and I have no intention of spending 4 hours behind the keyboard trying to share what I think I know in a way that the laymen can understand. To be short and blunt, if you can't check out the code and understand it for yourself it will take you many moons to understand the "secrets behind the GUI" for Truecrypt and then later, and separately, FreeNAS.
 

Knowltey

Patron
Joined
Jul 21, 2013
Messages
430
Or do you mean due to some network error the whole Truecrypt file can be corrupted and all data might be lost?

Yes, TrueCrypt isn't exactly well known to play well with sudden dismount.
 

Knowltey

Patron
Joined
Jul 21, 2013
Messages
430

Guys, have you never heard the phrase "for all I know"?

It's like you've never heard it. Cyberjock isn't saying that it is unsafe, he's simply saying that he can't guarantee that it is safe. I can't either. I don't know enough about encryption to go in and audit it myself and I haven't seen an audit on it from a trusted encryption auditor, so as cyberjock said, for all I know there is a backdoor in the encryption or some vulnerability to be exploited. Knowing iXSystems it probably is implemented properly, but I can't say that with certainty.

Hell, for all I know TrueCrypt has an exploit. It is currently being audited by a trusted auditor but until that is complete for all we know there may be a vulnerability or backdoor in it. That said I do sort of what DrKK does and use TrueCrypt containers in my home directory for stuff that I don't want easy access to. And I will have to agree with DrKK, CJ's aunt is smoking.
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
Guys, have you never heard the phrase "for all I know"?

It's like you've never heard it. Cyberjock isn't saying that it is unsafe, he's simply saying that he can't guarantee that it is safe. I can't either. I don't know enough about encryption to go in and audit it myself and I haven't seen an audit on it from a trusted encryption auditor, so as cyberjock said, for all I know there is a backdoor in the encryption or some vulnerability to be exploited. Knowing iXSystems it probably is implemented properly, but I can't say that with certainty.

Hell, for all I know TrueCrypt has an exploit. It is currently being audited by a trusted auditor but until that is complete for all we know there may be a vulnerability or backdoor in it. That said I do sort of what DrKK does and use TrueCrypt containers in my home directory for stuff that I don't want easy access to. And I will have to agree with DrKK, CJ's aunt is smoking.

Exactly. I cannot personally guarantee how good or bad any software package is. I'm not a developer, I'm not a cryptography genius, and I'm not ever going to try to discuss the merits of a program aside from mentioning that some other entity audited the code. Even then there's always that "possibility" that the other entity was paid to lie.

The bottom line, either you trust the developers and anyone that audits the code or you do your own auditing and trust that YOU know what you are doing.
 

panz

Guru
Joined
May 24, 2013
Messages
556
[... CUT ...] the various porn I have of Cyberjock's female relatives, things like this.

You two guys make me laugh... this is not tech support, it is antidepressant support! :)
 

Fox

Explorer
Joined
Mar 22, 2014
Messages
66
I use encryption. I backup all the keys, the individual drive keys as well.. I also have a backup of all my data.

I use encryption to offer peace of mind in case the system is stolen or a drive is sent in for replacement under warrenty. I doubt anyone is going to try to break the encryption in those cases.

Keep a backup of your data and sleep well at night.
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
You two guys make me laugh... this is not tech support, it is antidepressant support! :)

When I was in Canada years ago I went into a bookstore (I went in because a female friend I was with loved to read, so I went along). On book caught my eye towards the end of my walk through the bookstore. It was a book with a very attractive lady on the front cover in a somewhat erotic pose. The title was something like "So you want to kill yourself?" No joke, *every* single page was a centerfold that could have come from any adult magazine. They were in good taste though, nothing too hardcore or anything. I really wish I had bought it because it would make a great conversation piece today. :(
 

Ericloewe

Server Wrangler
Moderator
Joined
Feb 15, 2014
Messages
20,194
When I was in Canada years ago I went into a bookstore (I went in because a female friend I was with loved to read, so I went along). On book caught my eye towards the end of my walk through the bookstore. It was a book with a very attractive lady on the front cover in a somewhat erotic pose. The title was something like "So you want to kill yourself?" No joke, *every* single page was a centerfold that could have come from any adult magazine. They were in good taste though, nothing too hardcore or anything. I really wish I had bought it because it would make a great conversation piece today. :(

Well, the coffee table book market has been quite saturated with an assortment of books on modern art, not-so-modern art, trains/cars/airplanes, cute animals, not to mention the ever present competition from old magazines. I guess some tongue-in-cheek anti-suicide material is an appropriate eye catcher and conversation piece.
 
Status
Not open for further replies.
Top