Full Disk Encryption

[tjg091]

This is my first post on this forum.

I am looking to purchase a number of FreeNAS Mini XL's and one of the requirements we have is full disk encryption. It is unclear to me if the Mini XL includes full disk encryption (at rest). If anyone can answer this question, it would be appreciated.

tjg

 

[Redcoat]

Welcome to the forum.

FreeNAS does have that capability, See https://www.ixsystems.com/documentation/freenas/11.2/storage.html#managing-encrypted-pools

 

[Chris Moore]

This is my first post on this forum.

Welcome to the forum.

I am looking to purchase a number of FreeNAS Mini XL's

You should contact iXsystems directly so they can work with you on your requirements.

It is unclear to me if the Mini XL includes full disk encryption (at rest).

Full disk encryption (data at rest) is a feature, of the FreeNAS software. FreeNAS also has features to support management of self encrypting disks, which is a better way to go than the software encryption that can be done on regular drives that do not contain the encryption hardware internal to the drive.
I highly recommend contacting iXsystems sales staff. They are very knowledgeable.

 

[Chris Moore]

PS. You can call them here: 1 (855) GREP-4-iX which is 1 (855) 473-7449

 

[lei3E]

How secure is the encryption compared with LUKS?

Can a Non-US government decrypt my stuff?

 

[Heracles]

Can a Non-US government decrypt my stuff?

If your password for unlocking it is "password" then for sure, any kid around the block will be able to decrypt your stuff. But that is true for every encryption.

If your server is online and the intrusion is over the network, then Yes, anyone can decrypt your stuff without any effort. But again, that is true for every server-side encryption.

If your data is stolen from the laptop an insecure client is using to access it, again, it will be decrypted very easily.

Encryption at rest is far to be as a big plus as many people think it is. Worst, there is a lot of cases where encryption at rest turned to a self-inflicted ransomware instead of a protection.

If data need to be encrypted, it is probably better to do it at file level instead of block level. That way, it will be encrypted at rest in the server, but also at rest in a client. It may very well remain encrypted after root level access is gain to the server if it is not the one managing the keys. Encryption will also remain active over the network and more.

Block-level encryption is more an illusion and a risk than actual security.

 

[winnielinnie]

Block-level encryption is more an illusion and a risk than actual security.

I have to disagree. Real-world use shows otherwise:

FBI Unable to Decrypt Brazilian Banker's Data

Brazilian banker's crypto baffles FBI

After experts from the Brazilian National Institute of Criminology (INC) unsuccessfully tried to recover the data for five months, the Brazilian authorities decided to ask the help from an institution with more expertise in handling such problems – the United States Federal Bureau of Investigation. Brazilian media outfit Globo reports that the drives were sent to USA in early 2009 where the FBI tried to crack the encryption for the following twelve months.

The FBI failed to break the encryption protecting the data of a high profile banker investigated in the largest corruption and money laundering case in Brazilian history. The Bureau's experts gave up twelve months after receiving the seized equipment from the Brazilian authorities.

If you stump the Brazilian government and the United States FBI, it's safe to assume your data (at rest) is secure and inaccessible from unwanted eyes. This was a decade ago. TrueCrypt's successor, VeraCrypt, has undergone more improvements, better compatibility with open-source software licenses, and has been vetted by independent parties.

 

[Heracles]

Real-world use shows otherwise:

You misunderstand the problem. Here, the FBI has been blocked by encryption.

If data need to be encrypted, it is probably better to do it at file level instead of block level.

What I said is that BLOCK LEVEL encryption should be avoided, if and when encryption is indeed required.

As for the priority, just do some thinking here :
You suffer a security incident tomorrow. No choice, something bad will happen. Your last choice is :
--After the incident, someone got access to the data, but yourself also kept access to them
--Despite the incident, nobody accessed your data, but you do not have them anymore either.

What case will you face ? You will keep your data. That is, Availability is of a higher importance than Confidentiality.

Same logic here : Something happened and you are faced with two possible consequences :
--You do have access to data, but they have been tempered with
--You do not have access to data any more.

It is obvious to detect that data are missing and up to you to deal with that. On the other end, to detect that some data have been tempered with is almost impossible and to act on the base of falsified data can create complete catastrophe. That is, Integrity is of a higher importance than Availability.

As for the last security need, Authenticity, that is an even easier one... Integrity is to ensure that data has not been modified without authorization. What will define who one is and if he is authorized to modify some data ? Authentication. As a requirement for integrity, Authentication is of a higher importance than integrity.

At the end, the most important security needs are, in ordre :
--Authentication
--Integrity
--Availability
and as the very last of all,
--Confidentiality

So indeed, confidentiality is of much less importance than what most people think. And when needed, block level encryption is one of the least beneficial form of encryption.