I recently ordered a Framework DIY edition 12th gen laptop.

The DIY edition comes with a few storage options, all Western Digital NVMes.

I ordered the SN850 initially, but decided to return it to buy a NVMe with hardware encryption.

In the past I have always used LUKS / dm-crypt software based encryption.

This has the advantage of being open source, auditable, and widely used.

It is arguably more secure than trusting a drive manufacture has properly implemented secure encryption with no back doors, vulnerabilities etc.

However, it does mean that we are using CPU cycles to decrypt the data and the write patterns when using software based encryption may not be optimal for an NVMe.

When using an SED (self encrypting drive) the encryption is done on the fly by the drive itself.

On boot the drive is unlocked and any subseqent reads or writes will be transparenly decrypted / encrypted, until the drive is powered off.

I like the idea of offloading this work to the hard drive and for my threat model it should be more than enough.

980 Pro

The 980 Pro supports the OPAL 2 standard.

We have few options when it comes to enabling encryption.

1. Use Framework BIOS to manage locking / unlocking.

2. Use sedutil

Option 1 is convenient as we do not need to setup any additional software, everything is handled directly by the BIOS.

However the BIOS is not open source, so we cannot audit what it is doing, nor can we easily modify the behaviour if desired.

Furthermore, we do not know what kind of password hashing it uses, so if we move the drive to another device it may not be possible to unlock the drive.

Option 2 is a little more difficult to set up, but it is using an open source application called sedutil for setting up OPAL compliant drives.

This has been developed by the Drive Trust Alliance.

It has many advantages over using the BIOS directly.

• The drive can be locked / unlocked easily from a live CD with sedutil installed.
• The password can be changed from the running system.
• If we move the drive to another machine, it can be accessed so long as we used the same version of sedutil.
• It is open source, so we can modify the behaviour to our liking.

Option 1: Locking / Unlocking from Framework BIOS

The InsydeH2O UEFI BIOS setup utility that is on the Framework appears to support OPAL drives out of the box.

Prior to installing the 980 Pro, with the SN850 I had the option of setting an ATA password under the security tab.

This will block access to the drive, but the data is not actually encrypted and ATA passwords can potentially be bypassed.

After switching to the 980 Pro, we see a slightly different menu.

Under “Security” we now have a sub-menu “Storage Password Setup Page”.

Here we have options to set the Master HDD password, Something password, PSID revert etc.

After setting the storage and master password and rebooting, we are presented with a screen showing that the NVMe is locked.

Pressing Enter opens a password input dialog.

!Password input

After intentionally entering the incorrect password a few times we get this error screen:

!Too many incorrect password attempts

Lastly, I attempted a PSID revert to ensure the drive is recoverable directly from the BIOS if the password is forgotten.

The PSID revert will reset the encryption on the drive as well as securely erasing the drive contents.

The PSID is printed on a sticker on the NVMe drive.

PSID Revert

Option 2: sedutil

sedutil is an application for configuring OPAL 2 compliant self encrypting drives.

It was developed by the Drive Trust Alliance.

For a period, development on sedutil seemed to be halted, with little activity between 2017 and 2021.

For this reason there are many forks of sedutil.

I have chosen to use the ChubbyAnt fork.

This fork uses SHA512 password hashing instead of SHA1, which is used by the original sedutil.

For this reason it is not compatible with the original sedutil fork.

It will not be possible to unlock a drive that was locked with the ChubbyAnt fork with the original sedutil and vice-versa.

The fork also adds support for AMD Ryzen, and from diffing between the forks, it seems it can talk to drives that support OPAL, OPAL Lite, Pyrite.

I also found it easier to build the Rescue and PBA UEFI images, though this is not necessary as the prebuilt images.

Installation

ChubbyAnt sedutil have a helpful website for setting up encryption.

Opal 2 compliant drives have a “shadow” MBR (master boot record).

If we enable this shadow MBR, then when powered up the drive will only expose this MBR to the BIOS.

We install a PBA (pre boot authorization) image to this shadow MBR, which will be booted by the BIOS.

The PBA unlocks the drive, reboots, and then the “real” hard drive will be visible and the OS can be booted like normal.

I followed the instructions on the sedutil.com website which are also available on Drive Trust Alliance github wiki.

This worked without any issues and I was able to unlock the drive on boot through the PBA image.

When the drive is locked and the shadow MBR is enabled, the Insyde H2O BIOS utility no longer seems to recognises it as an OPAL drive.

After the drive is unlocked and the PBA sets MBR Done to yes, the BIOS can see the drive.

EFI Boot entry issue

After installing Arch linux I encountered an issue where after unlocking the drive through the PBA, the OS would not boot.

The BIOS complained that there was no boot media.

I disabled locking on the drive and the shadow MBR.

sedutil-cli -–disableLockingRange 0 <password> /dev/nvme0
sedutil-cli –-setMBREnable off <password> /dev/nvme0

This did not help, until I reinstalled grub through the Arch installation media.

Now Arch linux booted fine, but when I re-enabled locking, again it stopped booting.

It turned out I was hitting an issue that has been encountered by many others.

https://github.com/Drive-Trust-Alliance/sedutil/issues/27

When the laptop boots, as it cannot see the EFI entry when the shadow MBR is enabled it removes the EFI boot entry.

This can be verified by running efibootmgr.

Even after unlocking the drive the EFI boot entry is still gone, so we can no longer boot until after reinstalling grub.

There seems to be a few of options to work around this.

1. Modify the UEFI PBA image so the EFI application is at the same location as the Arch linux grub installation.

2. Modify the grub installation to install to the same place as the PBA image EFI application.

3. Install to a well known EFI path that is used for windows.

Patching the boot image looks something like this:

gunzip UEFI64--1.15-5ad84d8.img.gz


$ fdisk -l UEFI64--1.15-5ad84d8.img
Disk UEFI64--1.15-5ad84d8.img: 32 MiB, 33554432 bytes, 65536 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 217DC58B-BC57-4331-9775-6DB4F5E434D8

Device                    Start   End Sectors Size Type
UEFI64--1.15-5ad84d8.img1  2048 65502   63455  31M EFI System

>>> 2048*512
1048576


sudo losetup -f UEFI64--1.15-5ad84d8.img

NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE                               DIO LOG-SEC
/dev/loop0         0      0         0  0 /home/jack/iso/UEFI64--1.15-5ad84d8.img   0     512

$ sudo mount -o loop,offset=1048576 /home/jack/iso/UEFI64--1.15-5ad84d8.img /home/jack/iso/uefi_mount

However a much easier option is using the --removable option when installing grub.

From the Arch wiki:

Tip: If you use the option –removable then GRUB will be installed to esp/EFI/BOOT/BOOTX64.EFI (or esp/EFI/BOOT/BOOTIA32.EFI for the i386-efi target) and you will have the additional ability of being able to boot from the drive in case EFI variables are reset or you move the drive to another computer. Usually you can do this by selecting the drive itself, similar to how you would using BIOS. If dual booting with Windows, be aware Windows usually places an EFI executable there, but its only purpose is to recreate the UEFI boot entry for Windows. If you are installing GRUB on a Mac, you will have to use this option. If you execute a UEFI update, this update might delete the existing UEFI boot entries. Therefore, it is a potential fallback strategy to have the “removable” boot entry enabled. This causes grub to be installed to the same location as the shadow MBR.

After this change, the boot entry is no longer forgotten when the Shadow MBR is booted.