-1

I need to protect a few hundred thousand files stored on a drive on a Linux server. I am thinking full disk encryption with file encryption on top would be the best option. Failing that, file based encryption would be the next best option. However, I was asked to consider full disk encryption only as well.

With FDE using something like LUKs, my research lead me to believe that the data is only really protected when the system is off or the encrypted container is locked. When the system boots and unlocks the drive, isn't the data available and viewable as if it weren't encrypted?

  • Yes, though the same is true of file encryption like eCryptfs – AndrolGenhald Sep 4 '18 at 15:44
  • @AndrolGenhald So all full disk based encryption solutions have the same limitation? If I want the data to be protected primarily while the system is running, file-based would be best? – Mr Wizard Sep 4 '18 at 15:46
0

It really boils down to your usage scenario. What is commonly referred to as FDE is really "partition" encryption in which the encrypted container is a partition. LUKS is an example of an encrypted partition.

Encryption protects dead containers. Active use of an encrypted container requires decrypting it, however done correctly the original container is not actually decrypted, a secondary virtual decrypted container is created. This could be an in-memory only file for file based encryption or more commonly a driver interface that performs on-the-fly block encryption/decryption to accessed containers.

Your stated objection to LUKS implies that you are keeping your files on the booted partition that auto unlocks and mounts with startup. If this is not desired, use a separate partition that doesn't auto mount.

In file encryption the encryption container is a single file. Individual files must be individually decrypted for access. Using this for a large number of files can work but will likely be annoying.

The third option is a multi-file container. Instead of a "partition" container or a "single file" container, a multifile container is exactly that, it holds multiple files but is not itself a partition.

The catch in your question is the word "SERVER". If it's truly a server that multiple people are accessing, then either the server must unlock and make available the unencrypted content when running, or each person must unlock content for themselves. It all boils down to the question of who owns the keys? Servers typically need to be able to autostart from power failure or whatever. To do so without manual intervention means that the encryption keys are automatically accessible.

  • Even if the keys are not stored for automatically unlocking the system, it's possible to sniff the keys in transit if remote attestation is not in use. Actually a funny story, but a sysadmin I work with had hardcoded the encryption key in our initramfs boot script (which is, of course, unencrypted). I was horrified. The worst part is that he could have just automated sending the key over LAN. – forest Sep 4 '18 at 19:43
  • @user10216038 Yes, these files are on a server used by multiple people that needs to remain online 24/7. It would also need to unlock the partition automatically at boot. The files wouldn't need to be stored on the boot partition, but the partition would need to unlock at boot so the files are always available, which is the limitation I was questioning. If my understanding of that is correct, then FDE wouldn't be an option for me. I was wanting the files to always be in an unreadable format and decrypted when needed using gpg or similar. – Mr Wizard Sep 5 '18 at 13:53
  • If you want individual files to be "decrypted when needed", that's file level encryption by definition. However it comes with a significant Key Management problem. If multiple people are accessing the files then are they sharing a key or are there separate keys for every user? How will you manage key changes? Will these files be writable or readonly? As a general guide, shared keys are almost always a problem waiting to happen. – user10216038 Sep 5 '18 at 19:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.