FreeNAS with a full-disk encryption

[Arwen]

@Artiom N.
FreeNAS is certainly not the end all for home / small office NAS.

So yes, your best bet is to use something like OMV.

You may not be aware, but native encryption arrived for ZFS on Linux last spring. Though I personally would not use it in production for at least a year. This same code will make it to FreeBSD, but not soon. Then even more time before it arrives on FreeNAS. So Linux might be a good path for you. I even played with it on a test Linux box, but not as the root pool.

 

[freelan]

I am using zfs native encryption on Linux, it's RC2 and it's working fine.

 

[southwow]

I'm late to the conversation, but you may as well stick to plain old bsd. It's not an insult; I used to do a similar partitioning scheme on Solaris on old Sun mini-fridge sized 400's loaded with drives for production systems that collected factory data. FreeNAS is meant to make NAS operation simpler. If you're not following the use-case, the custom interface is basically useless... but the base OS can still accomplish what you need. You can even use webmin to manage it.

Edit:
Regardless of what you do, ZFS is the right file-system for data integrity

 

[kdragon75]

Why not? FreeBSD can do this. OMV, based on Debian, can too (I can do this in OMV, because I use full-system encryption on the several machines, but Linux ).
FreeNAS is FreeBSD with GRUB, tweaks, GUI and very poor installer (unlike OMV, which has the full-featured Debian installer).
After the installation I can make my own partition scheme for the system (i.e., I don't want use both SSDs as a mirror for FreeNAS).
Why can't I make a full-system encryption?
Is it difficult because GRUB?


This is offtopic, but pool encryption without system encryption is like a palliative (anyone who has access to the my device, can patch the software, even automatically (yes, I have it in the my threat model and I know about hacks, which can I do to pass it, but I don't want to make hacks, because I know the simple straight way: full-system encryption)).

At work with have half million dollar arrays built by IBM and NetApp, they don't encrypt the OS....

FreeNAS can't satisfy it, OpenMediaVault can.

Ok, enjoy OMP. Bye!

 

[Ender117]

I don't really get why, but it might be possible if you virtualize FreeNAS and encrypt the VM?

 

[fefe]

Wouldn’t be fair or make sense to use the TPM 2.0 chip on the motherboards for this purposes (given that the motherboard has one, as far as I know IBM has TPM 2.0 on newer the ThinkServers)?
It could make sure that the boot/OS is not tampered with (and if it has been tampered, than the system simply not start), it can auto decrypt the full disk if everything is fine, it could help in providing a lots of handy security related features.
BTW is freeNAS can use TPM 2.0 chip on the motherboard? I understand the point of existing BIG enterprises might not use such, however in Europe because of the new GDPR law for even big businesses FDE (Full Disk encryption) is a bare minimum.
With the revelation of Snowden and the 3 letter governmental organizations I think we all can use a bit more security especially if hardwares like the TPM 2.0 chip is exist. Why not use it?

 

[Heracles]

Hi Fefe,

There are basically no logical security that will survive a physical attack. Once a system is reached physically, basically all logical protection must be considered as defeated.

The purpose of a TPM is to offer a better protection in that specific situation : to offer some kind of physical control that even physical access will have difficulty to defeat. But really, once physical security is defeated, you must be ready to give up on every logical security that was inside that physical box.

This is why you must keep the cryptograms and keys apart : Cryptograms in one system and keys in a different one. Should something happen to the system with the keys, cryptograms are still safe and you can decrypt / re-encrypt to protect against the leaked keys. Should something happen to the cryptograms, they are still safe because the keys are nowhere to be found in that system.

The problem with all file system level encryption solutions (ZFS pool encryption, Mac OS X Filevault, Microsoft Bitlocker, ...) is that by definition you can not separate the key and the cryptogram. The two are part of the very same system and can not be separated. Because of that, whatever will happen to the cryptogram will also happen to the key and vice versa.

Unmonitored boot is of importance for most servers, so hard requirements for human action at boot like providing a passphrase is often a no-go.

There are ways to do encryption at rest and keep cryptograms and keys apart. File system encryption is just not that way.

The entire idea about encryption is to substitute access control to the data by access control to the key. Should both be managed by the same access control system and accessible to the same entity, the substitution is completely useless. For pool encryption, data are protected by filesystem access control, so are the keys.

I wrote a thread about pool encryption recently. I suggest you get a look at it.

 

[fefe]

Hi Heracles,

I just read your thread, and I am not entirely agree with you on it. I agree with some of the comment you received as the point is to let the user know about the Pro/Cons of it and allow him to decide if it is worth for him/her to take the extra steps/responsibility/care for it by implementing the whole thing properly including managing the keys well and responsibly etc.

Now here in the EU because of the GDPR there is not much option when one stores sensitive identifiable data, but to implement reasonable solutions depending on the type of data and its importance/confidentiality to make sure it stays secure from prying eyes/hackers.

The purpose of a TPM is to offer a better protection in that specific situation : to offer some kind of physical control that even physical access will have difficulty to defeat. But really, once physical security is defeated, you must be ready to give up on every logical security that was inside that physical box.

Yes. And that not making it not needed.

On the contrary if you choose a good long passphrase of over 50 char or longer for LUKS and have the TPM2 chip encrypt the passphrase, even if you have physical access to the drives (by taking the drives out) good luck to even brute force it.
If for example the whole NAS unit is taken by an nefarious hacker, than it really comes down how the FreeNAS OS is using the keys and store them in MEMORY, caches etc, as the attacker should definitely has to do something before totally shut down the server if he really want any/big chance to get to the data as the TPM2 chip (same as with Yubikey) is secure by default and do not exposes the private keys outside of the chip.

I personally believe that encryption/privacy was and is important (I believed it even before GDPR, which by the way would have been better in effect with providing practical solutions too, and not just force companies to abide by it).

The whole point of encryption/securing-data-at-rest is to make it harder/impossible to get to the data being protected by proper software/hardware implementation and responsible key management/administration etc. of security/cryptographic solutions and aim to the best compromise of conveniency vs. security DECIDED by the DATA OWNER.

If that would be true that implementing encryption would be pointless because of poor/improper implementation, than why the effort of creating TPM2.0/LUKS/RSA/DH/TLS/HTTPs, why not just serve the whole data in the clear and make it easy to get to it exposing your/others credit cards, financial data/medical data/ private live etc.?

I think the KEY IS: properly implementing and advance/fix already existing security Hardware/Software solutions. And IT SHOULD BE IMPORTANT for anyone who cares about privacy and respect other's privacy as well. Especially when it comes to companies who are knowledgeable and servicing solutions which deals with data even if it is inconvenient. Please, please let the user decide how far he want to go about it.

I think supporting/implementing and make it more and more practical to use and also promote the use of HSMs (Hardware Security Module), Yubikey or LDAP is also would be a good solution for key management for FDE and other encryption.

 

[InfoBox]

Hello People,

I agree with fefe. I also prefer to keep all my drives encrypted.

There are people, who think, even encryption of data is a security-risk cause of possibly loosing the data cause loos the password / passphrase. But I think, that is a decision, the owners of a server or of the data has to make for themselves.

It may be right, that all encryption is not perfect and with quantum computing it could be easy to decrypt it nearly in time. But we all know how sensible personal data can be. So, it should be totally legitimate to come to the decision, that all data on a hardware is worth to be protected by encryption as good as possible and leave no thinkable flaws.

FreeNAS is not FreeBSD, but it sits completely in top of it. As FreeNAS is now using the original FreeNAS-Installer, it should be possible and very easy to allow admins to configure their system to their personal needs. I'm sure, that FreeNAS does not store the needed configurations in any other places then FreeBSD does. So encryption of boot-disks, and even of chases and swap will be totally transparent for FreeNAS and there will be no more effort necessary as to show more options of the FreeBSD-Installer then actually.

It would also be very nice - but this goes more in direction to the FreeBSD-Developers - to support 2-factor authorization or also FIDO2 at login- and drive-encryption-level.

If you think, that I'm paranoid. Yes.

 

[InfoBox]

Hello People,

I agree with fefe. I also prefer to keep all my drives encrypted.

There are people, who think, even encryption of data is a security-risk cause of possibly loosing the data cause loos the password / passphrase. But I think, that is a decision, the owners of a server or of the data has to make for themselves.

It may be right, that all encryption is not perfect and with quantum computing it could be easy to decrypt it nearly in time. But we all know how sensible personal data can be. So, it should be totally legitimate to come to the decision, that all data on a hardware is worth to be protected by encryption as good as possible and leave no thinkable flaws.

FreeNAS is not FreeBSD, but it sits completely in top of it. As FreeNAS is now using the original FreeNAS-Installer, it should be possible and very easy to allow admins to configure their system to their personal needs. I'm sure, that FreeNAS does not store the needed configurations in any other places then FreeBSD does. So encryption of boot-disks, and even of chases and swap will be totally transparent for FreeNAS and there will be no more effort necessary as to show more options of the FreeBSD-Installer then actually.

It would also be very nice - but this goes more in direction to the FreeBSD-Developers - to support 2-factor authorization or also FIDO2 at login- and drive-encryption-level.

If you think, that I'm paranoid. Yes.

I would like to add, that FreeNAS or an Admin may store any kind of sensitive data some where on the root-disk, like passwords for a data storage. the private part of an certificate. anything like this. I know, this should not happen in an properly configured system. But we all know, that thins things happen.

This for example is one kind of problem a risk, that can be reduced with encryption the root-pool.

 

[Heracles]

Again guys, encryption at rest is not the problem. Even myself do at rest encryption. I just don't do it using the filesystem because that would join the cryptogram and the key in a single system. Here, I do encryption with Nextcloud in a docker outside FreeNAS and once every file is encrypted, only then it is written to FreeNAS. FreeNAS only receives encrypted data. That way, on every system on which I replicate using ZFS, everything remains safe.

Encryption replaces access control to the data with access control to the key.
If the key is protected by nothing else than Operating System rights, then access to data is not protected beyond the same access rights enforced by non encrypted filesystem. You end up with no gain and all the risks of loosing everything.

Do a little search in the forum and see how many ended up locked out of their own encrypted pool.

Feel safe if you wish, but there is a thousand plus more chances that you will end up suffering your self inflicted ransomware more than being protected against any actual incident.

See it in another way : You suffer a security incident tomorrow. No choice about this : something bad is happening despite everything you did trying to prevent it. No security is perfect, not even yours. But luckily for you, you can take a last action. In one case, someone else end up able to read your data but after the incident, you still have access to it. In the other, no one accessed your data, but you do not have them anymore yourself either.

Which case will you face ? You will keep your data, just like everyone. Don't say that you will loose this instance and restore from backups. This helps to illustrate the situation about something like encrypting the backups or not. If you do, the incident is exactly that your backups are not readable anymore because you locked yourself out with your own encryption. So is it better to be able to restore from a clear text backup or better to loose everything in the name of not leaking anything ?

For basically every case, physical security and proper access control is much safer than encryption, even more than filesystem based encryption.

 

[fefe]

@Heracles

Before saying anything: I want to say that my point in all of this is the fact that it is not implemented yet and that there is no any option/power/control given to the USER/DATA-OWNER to decide if he wants to use it and if he responsible enough to implement it correctly. However the proper and responsible implementation can be aided by good, clear and concise HOWTOs plus it can be implemented into the workflow of the set-up function in the FreeNAS OS/software level to make sure initially all needed things are taken care of ie. maybe force the user to have 2 USB to save the ecnryption/decription key or the passphrase and give warning if that is skipped and show alert regularly until that is implemented - no matter what, the one who uses the Software should and always hold the responsibility to implement it properly and the FreeNAS or any other software can just aid the process and make sure there are proper alert and HOWTOs to implement it properly.

I have to disagree with you as WHAT I do not like and cannot agree with you and frankly never will, is that YOU IMPLY that data-at-rest is unnecessary whereas if you are looking in enterprise set-ups and all the technology out-there you can find just the opposite (I am thinking about TPM2.0 chip/LUKS/SED(Self Encrypted Disk)/NBDE(Network Bound Disk Encryption – currently RedHat implemented it already fully ;-) )./etc. . . .), except that it is not IMPLEMENTED into a great product such as FreeNAS. Although, NOT THAT any other NAS product/OS like Synology/QNAP does that although QNAP has some good momevemnt into this direction, however it is not yet supported in any of these products/OSes. I do not know if other NAS software/OS implemented it as default, at least I did not see anything on it, but be my guess and prove me wrong on it if yes. Which is kind of sad as the Base OS what they use to derive their product supports it(LUKS/TPM2 chip/NBDE), so I do not get what the matter to pull it into and implement it into the FreeNAS base.

If you use the TPM2 chip with SED HDDs, despite the key being on the same file system, you cannot extract it as it is already encrypted thus you see no file system except a bunch os gubleguk until you decrypt it. Moreover if you use SED, than the encryption/decryption is independent of the OS and as such waaaayyy more faster and it less hits your NAS's performance. If you use LUKS as well on top of that than you also gain more speed as encryption/decrytion is transparent i.e. OS level. If you do this above with the TPM2+SED and would add an NBDE set-up using TANG server locally, than your disks are safe at rest so long they are inside locally and given that the tang server is available and all credentials are correct, ie the bootloader and the OS is not tampered with which is made sure by using the TPM2 chip properly.

In my point of view, TPM2+LUKS should be the bare minimum for data at rest which gives you very good protection for data-at-rest.

Physical security is good (given that you can implement it properly), however that is not always the case in every SMBs to the point which makes really sense, and for example just lock it into a safe for physical security which is kind of 'WHATTTT???' !!

Please do not be confuse and make one solution less important than the other, there is a reason they have been created, I am thinking here to not be confused about authorization(ACLs) and data-at-rest(f.ex. LUKS) they both are important to implement and serve totally different purpose and solves different aspect of protecting your data and its access.

What you describes using NextCloud is good, so long it is not on the same physical machine and that the Host OS is already implements LUKS at the minimum with strong enough passphrase, than I am sorry to say but, than you just have a false sense of security.

 

[Heracles]

Hey fefe,

is that YOU IMPLY that data-at-rest is unnecessary

Well, you clearly did not read or think on that one... The very first words of my reply were :

Again guys, encryption at rest is not the problem. Even myself do at rest encryption.

So No, I do not imply that encrypting data at rest is bad.

As for the TPM, it is true that its purpose is to increase the physical protection of the key. But do a little search about "tpm fail" and you will find that last week again, new vulnerabilities were posted about how to recover crypto keys from TPMs.

If you need encryption, then do it. But don't leave the key in the keyhole. Don't leave the key with the cryptogram itself. When doing pool encryption, key is in the keyhole 100% of the time the server is running no matter what. When the system is not running, it still is in the keyhole 90+% of the time, being cleartext in the system or somewhere close as backups. It is much simpler not to leave the key in the keyhole when doing any other kind of encryption.

And again, that is true for all filesystem-level encryption like Bitlocker, Lucks, FileVault and more.

But by all mean, enjoy your self-inflicted ransomware and join the lot of so many users who already lost their data to their own pool level encryption,

 

[fefe]

@Heracles

Well, you clearly did not read or think on that one... The very first words of my reply were :

My bad.

Yes, you are right the key is in the Memory and that you cannot prevent no matter what encryption to use. It is just impossible for it. That is not an argument on security.

What is important that the DATA-AT-REST is encrypted.

Honestly because other has not been implemented the functionality is not an argument to not have it the first place.

There are still belts installed in the cars and one entitled to use it in Europe at least and lots and lots of idiots being killed because of not using it and also because using it. But still, it does being made, it is safer to use and the argument of people incorrectly or not using the belt is not being used to NOT have a belt. Isn't that.

Because of someone's incompetency to implement something (function/technology) properly doesn't make the it not needed.

I am using encryption and as you mentioned you use it too so what is the real argument/issue here to not implement proper security measures for data-at-rest?? Honestly I do not think if you would ask Snowden about it he would say please Not use LUKS/TPM2 etc.

Just a note it would be far more better if the OS would encrypt the memory and the CPU(which actually being made by intel for now it is not yet there for full production use) as well.

BTW:

And again, that is true for all filesystem-level encryption like Bitlocker, Lucks, FileVault and more.

Yeah and that would not be true in your NextCloud case hmm..? Is that any difference???

Honestly I think your argument is just goes on an on and on on ... based on others failure to be competent in implementing the encryption properly.

But do a little search about "tpm fail" and you will find that last week again, new vulnerabilities were posted about how to recover crypto keys from TPMs.

Oh and that is an argument against not using TPM2 chips???? You are saying....? doesn't even SSH/TLS/SSL/DiffieHelman/etc. has vulnerability and still being used to make it more harder to anyone to access what is being encrypted with it? Come on!!

IF TPM chip fails., you stillllllll shoulddd have the LUKS passphrase, if you do not well... too bad, actually your bad who did not have that saved or printed for recovery purposes.

 

[Heracles]

Yeah and that would not be true in your NextCloud case hmm..? Is that any difference???

Indeed, the case is VERY different with Nextcloud. At least, the way I configured it here.

Nextcloud is running from a server outside of FreeNAS. So is its database. Everything encrypted by Nextcloud is protected by keys that are in the database and not in the filesystem where the data are. Once a file is encrypted, only then it is written to FreeNAS. That way, FreeNAS only sees cryptograms and never touches the keys. The same way, by itself, the database server only sees keys and never touches the cryptograms.

That way, keys and cryptogram are never stored together, so the key never stays in the keyhole.

The only moment where keys and cryptograms are present together is in the Nextcloud docker container. So in my case, no incident, physical or logical, against FreeNAS can access anything. Same for the database. Only a complete control of the Nextcloud frontend can expose the cryptogram.

Even here, Nextcloud offers End-to-End encryption where keys are handled by the clients instead of the server. That way, even a fully compromised Nextcloud server will not be able to access anything. Here, I consider that End-to-End as more risk than security (same way I do for pool-level encryption) so I don't do it.

But indeed, there are ways to do encryption at rest while keeping keys and cryptograms apart. Nextcloud is capable of doing just that and that is the way I do.