Self-encrypting drives, Secure Boot, and UEFI tricks

an HDD with a label on it that says "ENCRYPTED"

A word of advice

You should not solely rely on hardware encryption! Unless you reverse-engineer the firmware, you don’t know how the drive implements the encryption, therefore you should NOT trust it!

Study on firmware weaknesses in SSDs: https://www.ru.nl/publish/pages/909275/draft-paper_1.pdf

Edit #1 | July 23 2024

According to a research team at RedHat* hardware encryption is weaker and slower than software-based FDE.

For a tutorial on how to encrypt your drive using cryptsetup’s support for SED (--hw-opal and --hw-opal-only), that is, encrypting the drive twice using HW and SW encryption or just using HW encryption with LUKS2, see: https://alexdelorenzo.dev/articles/cryptsetup-luks-self-encrypting-drives

* For more information on this issue, you might want to watch this talk:

Self-encrypting drives

A self-encrypting drive (SED) is basically a drive that is capable of hardware encryption.

All you need to know, is that a SED has a pre-boot authentication (PBA) image which the UEFI/BIOS finds and boots, the PBA presents you with a prompt where you enter the drive password, then the PBA decrypts the drive and usually reboots the system keeping the drive unlocked.

After you shut down your computer, you also shut down the drive, more specifically: the power to the drive. When the drive loses power, it locks itself, end of story. When you start your computer, the UEFI finds the PBA, boots it, and presents you with an input screen.

How do you encrypt an SED?

In summary, nowadays, we have a tool called SEDutil which contains most of the stuff you need for dealing with SEDs.

First off, you need to check if your drive is even capable of hardware encryption.

The sedutil command for that would be:

# sedutil-cli --scan

If you get something like:

[sudo] password for tux:
Scanning for Opal compliant disks
/dev/nvme0  2      Samsung SSD 980 PRO 500GB

then your drive is using the Opal v2 specification (the second value after the drive path). It’s not really important what specification your drive uses, what’s important is that your drive is capable of encrypting itself.

Actually encrypting the drive

In reality, you only need three core commands:

  1. sedutil-cli --initialsetup drive_password path_to_drive

    The drive name is something like nvme0n1 or nvme0n2.
    So, the path would be something like: /dev/nvme0n1

    drive_password is the password used to encrypt/decrypt the drive.

  2. sedutil-cli --loadPBAimage drive_password pba path_to_drive

    Get the PBA from here if you have a Ryzen CPU: https://github.com/ChubbyAnt/sedutil/releases
    The PBA name is UEFI64*.img

  3. sedutil-cli --setMBREnable on drive_password path_to_drive

PSID Revert

If the initial setup failed, then you most likely need to reset the encryption on the drive.

In most cases, the drive is already encrypted but unlocked with an unknown password from the factory.

You may try to find this password using: sedutil --printDefaultPassword path_to_drive

If that fails, you’ll need to reset the password.

To do that, you need to physically look on the SSD for a PSID and issue the following command:

sedutil --PSIDRevert drive_PSID path_to_drive

UEFI complications

If your UEFI is the same as mine, it will quite easily forget the boot entries, this happens for a simple reason: the (unlocked) device in the boot entry is not available at boot, and so the UEFI deletes it.

At this point there are only a few things you can try, for example:

I personally tried to find a path in the ESP that the UEFI would try to boot, in my case it was: ESP\EFI\Microsoft\Boot\bootmgfw.efi

So, I installed rEFInd, renamed it to bootmgfw.efi and moved it to that location.

Things to know about rEFInd:

Secure Boot

Despite what all the wikis say, you CAN enable Secure Boot, all you need is to enroll your own keys to the UEFI and sign the PBA.

A good guide is available at: https://github.com/Drive-Trust-Alliance/sedutil/issues/259

Useful links:

Edit#0 | Jan 30 2024

In August of 2023 I took a stab at making my own pre-boot authenticate image. I wanted it to be differenent from others, have a different greeting message and maybe play some games while at it.

In the end, I created what I call UPBADOOM, or Uncomplicated Pre-Boot Authentication and DOOM image. Before unlocking the disk, you have the option of playing the original DOOM.

If you’re curious and want to try it, it is available on my GitHub: https://github.com/turtureanu/upbadoom