1

I have a question relating to implementing encryption of data at rest. This is possibly more suited to another stackexchange site, so please let me know where would be better to post if I'm a little off base.

My system has an NVME drive with OPAL 2.0 hardware encryption and a TPM 2.0 module. I am running Ubuntu 20.04 with the 5.8 kernel (if that's relevant).

The NVME contains the operating system partitions (/boot, /, etc.) and there is a separate set of self-encrypting drives to hold the data that the system handles.

The data will be protected while the system is powered off as the disks have encryption enabled. When in use, the system is configured and used via a web interface so the system requires only a network connection to be operational.

I want to protect the operating system and the proprietary data processing code that is stored on it, along with the configuration information. I can set a passphrase on the NVME drive, but then the system prompts me for a password when I boot. This is not ideal as I will have to tell the customer the passphrase for them to use the system, and they will need a keyboard and monitor in order to enter the password - not ideal for a headless system.

While investigating this I have come across several guides which claim to give "Full Disk Encryption" but they using software encryption and not encrypting the /boot partition. This, to my mind, is not "Full Disk Encryption". It is "Partition Encryption" at best. Despite this I have configured my system with an unencrypted /boot partition and a LUKS encrypted LVM for the / partition. It is automatically unlocked during boot by clevis after the TPM gives the passphrase to the system. Along the way I have discovered the importance of Secure Boot, PCRs and MOKs. It's been quite the learning experience.

While I have a working solution I feel that I could get a small performance gain by using the hardware encryption available on the NVME disk, then I can remove the software encryption. But, I cannot find any guides or published solutions that will allow the system to boot unattended in a headless configuration. This seems like it should be possible, but I cannot find the right combination of keywords to get to the solution. The key requirements (pun intended) I have are:

  1. the disk should not be accessible in any other system, even if the TPM is transplanted to another chassis with the disk,
  2. the system should not boot from any other media, or if booted from other media the disk should remain locked,
  3. if the boot command is altered the disk shall remain encrypted (i.e. to prevent entering single-user mode or changing the init command), although with full disk hardware encryption, this is probably out of the scope of this question as the disk is already unlocked when booting.

tldr; Full Disk Encryption on Linux is frequently Selected Partition Encryption. How can I boot from a hardware encrypted disk without requiring interactive passphrase entry?

2
  • 1
    Be aware that historically many SEDs were found to be lacking security wise, and I personally would be very sceptical of the claims vendors make about the security of their products.
    – cisnjxqu
    Jul 2 at 19:49
  • I'm aware of the concerns around hardware encryption on particular devices. When weighing up all the considerations I've gone with a "best effort" basis for this protection of the data. Is the HW encryption option more secure than the SW encryption? If the HW encryption is "good enough" is there a performance gain from turning off the SW encryption?
    – fishter
    Jul 3 at 8:22
0

If you are flexible with the requirement where you do not use NVME drive with OPAL 2.0 hardware encryption, you can achieve this with Trusted Boot using TPM along with LUKS. In this case, you have to follow the below process

  1. Configure System for trusted boot with TPM 2.0.
  2. Use TPM to protect LUKS keys and seal them with TPM.
  3. TPM will only release the LUKS keys if the boot process is trusted

The above process can be configured without password option.

Now, if you follow the procedure as mentioned above, In all the below cases TPM won't release the LUKS keys since boot measure will fail.

the disk should not be accessible in any other system, even if the TPM is transplanted to another chassis with the disk,

the system should not boot from any other media, or if booted from other media the disk should remain locked,

For the below option, you can just disable the single user mode from the GRUB configuration.

if the boot command is altered the disk shall remain encrypted (i.e. to prevent entering single-user mode or changing the init command), although with full disk hardware encryption, this is probably out of the scope of this question as the disk is already unlocked when booting.

2
  • Thanks @saurabh. This is the solution I've already implemented, but it seems a waste to have the hardware encryption available and not used.
    – fishter
    Jul 3 at 8:15
  • NVME encryption won't save you from attack scenarios 1 and 2. Also, you need to check how secure is NVME drive encryption you are using. But if you want to use hardware encryption the possible solution is using TPM with NVME encryption where you store NVME keys in TPM and sealing them and NVME fetch keys from TPM. If possible, this implementation will save you from attack scenarios 1 and 2 and also without password. But I'm yet to see this implementation in work.
    – saurabh
    Jul 3 at 8:51

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.