Self-encrypting drives

Related articles

• Data-at-rest encryption
• Trusted Platform Module
• dm-crypt/Encrypting an entire system

Hardware-based full-disk encryption (FDE) is now available from many hard disk (HDD) vendors, becoming increasingly common especially for solid state drives. The term "self-encrypting drive" (SED) is now common when referring to HDDs or SSDs with built-in full-disk encryption. OPAL is a set of specifications for self-encrypting drives developed by the Trusted Computing Group.

Overview

Many self-encrypting drives available today implement the OPAL, Ruby or Enterprise standards developed by the Trusted Computing Group (TCG). Other standards such as Opalite and Pyrite only offer a subset of the functionalities offered by OPAL, and might not even offer any actual encryption of data at rest [1]. The hardware manufactured according to the standards is labeled accordingly.

Unlocking of the drive can be done during operating system runtime using software utilities, in a pre-boot authentication environment, or with a #BIOS based ATA-password on power up.

Tip: "Encryption" in the context of this page refers to hardware-based encryption. See Data-at-rest encryption#Block device encryption and Data-at-rest encryption#Stacked filesystem encryption for software-based encryption.

Refer to the #Advantages and #Disadvantages sections to better understand and decide if hardware-based full-disk encryption is what you want.

Key management technical implementation

Tip: This section is important to understand the core concepts behind effective key management, and secure erasure of the disk.

Key management takes place within the disk controller and encryption keys are usually 128 or 256 bit Advanced Encryption Standard (AES).

Self-encrypting drives adhering to the TCG OPAL 2.0 standard specification (almost all modern self-encrypting drives) implement key management via an authentication key, and a 2nd-level data encryption key. The data encryption key is the key against which data on the drive is actually encrypted. The authentication key is the user-facing 1st-level passphrase which decrypts the data encryption key (which in turn decrypts the data). This approach has specific advantages:

• Allows the user to change the passphrase without losing the existing encrypted data on the disk
  • This improves security, as it is fast and easy to respond to security threats and revoke a compromised passphrase
• Facilitates near-instant and cryptographically secure full disk erasure.

For those who are familiar, this concept is similar to the LUKS key management layer often used in a dm-crypt deployment. Using LUKS, the user can have multiple different keys (passphrases or keyfiles) to decrypt the master-key, which in turn decrypts the underlying data. This approach allows the user to change or revoke these keys as required without needing to re-encrypt the data, as the master 2nd-level encryption key is unchanged (itself being re-encrypted by the new passphrase).

In fact, in drives featuring full-disk encryption, data is always encrypted with the data encryption key when stored to disk, even if there is no password set (e.g. a new drive). Manufacturers do this to make it easier for users who do not wish to enable the security features of the self-encrypting drive. These self-encrypting drives can be thought of as having a zero-length password by default that always transparently encrypts the data (similar to how passwordless SSH keys can provide somewhat secure access without user intervention).

If a user wishes to "enable" encryption at a later stage, they are able to configure an authentication key (such as a passphrase) which encrypts the existing data encryption key. The user will then be prompted for their passphrase when decrypting the data encryption key in the future. Crucially, because the existing data encryption key is not regenerated, setting a passphrase allows for the drive to be locked while preserving existing encrypted data on the disk, avoiding the need for the drive to be re-encrypted. On the flip-side, there is no way to re-encrypt the data itself, other than a secure full disk erasure.

Advantages

• Easier to setup (compared to software-based encryption)
• Notably transparent to the user, except for initial bootup authentication
• Data-at-Rest protection
• Increased performance (CPU is freed up from calculations to encrypt and decrypt)
• The main CPU and RAM are eliminated as possible attack targets
• Optimally fast and #Secure disk erasure (sanitation) (regardless of disk size)
• Protection from alternative boot methods due to the possibility to encrypt the MBR, rendering the drive inaccessible before pre-boot authentication

Disadvantages

• The configuration of suspend and hibernate modes is difficult and may be impossible, depending on the systems' EFI implementation.

• A re-encryption of the data is not possible without a secure disk erasure.

• Exploitations

• Constant-power exploits

Typical self-encrypting drives, once unlocked, will remain unlocked as long as power is provided. This vulnerability can be exploited by means of altering the environment external to the drive, without cutting power, in effect keeping the drive in an unlocked state. For example, it has been shown (by researchers at University of Erlangen-Nuremberg) that it is possible to reboot the computer into an attacker-controlled operating system without cutting power to the drive. The researchers have also demonstrated moving the drive to another computer without cutting power.[2]

• Key-in-memory exploits

When the system is powered down into S3 ("sleep") mode, the drive is powered down, but the drive keeps access to the encryption key in its internal memory (NVRAM) to allow for a resume ("wake"). This is necessary because for system booted with an arbitrary operating system there is no standard mechanism to prompt the user to re-enter the pre-boot decryption passphrase again. An attacker (with physical access to the drive) can leverage this to access the drive. Taking together known exploits the researchers summarize "we were able to break hardware-based full-disk encryption on eleven [of twelve] of those systems provided they were running or in standby mode".[3] Note, however, S3 ("sleep") is not currently supported by sedutil (the current available toolset for managing a TCG OPAL 2.0 self-encrypting drives via Linux)

• Compromised firmware

The firmware of the drive may be compromised (backdoor) and data sent to it thus potentially compromised (decryptable by the malicious third party in question, provided access to physical drive is achievable). A study demonstrated methods for compromising device firmware, as well as applying invalid passwords to access data on OPAL devices.[4] If data is encrypted by the operating system (e.g. dm-crypt), the encryption key is unknown to the compromised drive, thus circumventing this attack vector entirely.

Linux support

The kernel supports OPAL self-encrypting drives via the BLK_SED_OPAL option.[5] All officially supported kernels are built with this option enabled.

msed and OpalTool, the two known Open Source code bases available for self-encrypting drives support on Linux, have both been retired, and their development efforts officially merged to form sedutil, under the umbrella of The Drive Trust Alliance (DTA). sedutil is "an Open Source (GPLv3) effort to make Self Encrypting Drive technology freely available to everyone."

cryptsetup, the command line utility for dm-crypt, gained limited OPAL support. See the cryptsetup 2.7.0 release notes to check whether its capabilities suffice for your purpose.

Using sedutil

Install the sedutil^AUR package, which contains the sedutil-cli tool, and helper scripts to create a custom pre-boot authorization (PBA) image based off the current operating system in use (e.g. for setting a custom console keymap). Alternatively, you can install sedutil solely for acquiring the sedutil-cli toolset, but download and use the precompiled PBA image (for BIOS or UEFI) provided by the Drive Trust Alliance.

Note: UEFI support currently requires that Secure Boot be turned off.

For devices connected via SATA, libata.allow_tpm must be set to 1 (true) in order to use sedutil. Either add libata.allow_tpm=1 to the kernel parameters, or by setting /sys/module/libata/parameters/allow_tpm to 1 on a running system.

Warning: Using sedutil with external drives, even if sedutil claims the drive supports OPAL, has been reported as bricking them. For example, WD My Book external hard drives owners should set up encryption with the WD Security utility in Windows, and then use sg_raw for unlocking it. There is also a utility that supports setting up and unlocking such drives here: wdpassport-utils

Encrypting the root (boot) drive

These instructions assume you have the sedutil-cli tool installed (via the AUR, or by other means)

Check if your disk supports OPAL

# sedutil-cli --scan

If you get something like

Scanning for Opal compliant disks
/dev/sda No  LITEONIT LMT-256L9M-11 MSATA 256GB       HM8110B

then your disk does not support OPAL. On the contrary, the following output means OPAL standards 1.0 and 2.0 are supported, as the drive has a 2 (or a 12) in the second column indicating OPAL 2 support:

/dev/sda 12  Samsung SSD 850 EVO 500GB                EMT02B6Q

Windows version of sedutils output:

\\.\PhysicalDrive0 12  Samsung SSD 850 PRO 512GB                EXM02B6Q

Download the rescue image (optional)

Note that this rescue image was built in 2017 and its PBA-Image, on newer AMD-Laptops causes the internal keyboard-input to fail - thus requiring an external keyboard to enter the Disk Password. You might want to build your own PBA instead.

Download a rescue system for a machine provided by the Drive Trust Alliance, e.g. RESCUE64.img.gz.

Note: UEFI support currently requires that Secure Boot be turned off.

Create a bootable drive

Decompress the rescue image (if required):

$ gunzip RESCUE64.img.gz

Create a bootable drive using the downloaded rescue image, for example using dd:

# dd bs=4M if=path/to/RESCUE64.img of=/dev/sdx status=progress conv=fsync oflag=direct

Using Pre-boot Authorisation (PBA)

The following steps will install a PBA image in your EFI/BIOS which will start before your system and prompt you for a password. If the password is correct, it will unlock the drive and reboot into the normal operating system boot loader.

Encrypting your drive

Warning:

• These steps must be executed from the rescue system.
• These steps will enable encryption for the entire drive (locking range 0). Whilst this does not usually delete the data, always make sure to have a backup.

Enable locking

Boot into the rescue system and use the output of blkid to help identify the correct drive, e.g. /dev/sdx.

Setup the drive initially, which will be set both SID and Admin1 passwords to the same PASSWORD of your choice:

# sedutil-cli --initialsetup PASSWORD DRIVE

Then enable the global locking range 0 (i.e. the entire drive):

# sedutil-cli --enablelockingrange 0 PASSWORD DRIVE
# sedutil-cli --setmbrdone off PASSWORD DRIVE

Set a password

To optionally change the PASSWORD from initial setup prior to continuing with setup:

# sedutil-cli --setsidpassword PASSWORD NEW_SID_PASSWORD DRIVE

will change both the SID and Admin1 to NEW_SID_PASSWORD. To only change the Admin1 password:

# sedutil-cli --setadmin1pwd PASSWORD NEW_ADMIN1_PASSWORD DRIVE

Install the Pre-boot Authorisation

Install the Pre-boot Authorisation (PBA) image:

# gunzip /usr/sedutil/UEFI64-*.img.gz
# sedutil-cli --loadPBAimage PASSWORD /usr/sedutil/UEFI64-*.img DRIVE

Power off the computer to lock the drive.

When the computer is next powered on, the PBA should ask for your password; then unlock the drive and chain-load the decrypted operating system.

Troubleshooting: PBA Cold Reboot Locks Drives Again

In some cases, the PBA will load, accept the password, and unlock the drives but when chain-loading to the decrypted operating system it will do a "cold" reboot which powers off the disks for a moment and result in the drives locking again. So you get stuck in a loop of always unlocking the drives but never booting from them.

If this is the case, you will need to edit the UEFI-*.img to guarantee it does a "warm" reboot:

# losetup --find --show ./UEFI64-*.img 
# partprobe /dev/loop0
# mount /dev/loop0p1 /mnt
# cd /mnt/EFI/boot
# $EDITOR syslinux.cfg # add " reboot=warm" (no quotes) to the end of the line starting with  "append"
# cd -
# sync
# umount /mnt
# losetup -D

Now you can copy the image to the drive again with:

# sedutil-cli --loadPBAimage PASSWORD ./UEFI64-*.img DRIVE

If you are using the recovery image the above might not work (losetup -f ./UIEFI64-*.img fails with no such file), you can edit the file on your computer and copy it on the recovery USB drive (but after the end of the recovery image)

# dd bs=4M if=UEFI64.img of=DRIVE seek=100

seek=100 will skip 400 MiB from the start of the drive to avoid overwriting the recovery image itself.

Then, once the recovery is started you can get your image:

# dd bs=4M if=DRIVE of=UEFI64.img skip=100 count=10

count×bs should be more then the file size.

Truncate file to actual size:

# truncate -s IMGSIZE UEFI64.img

Troubleshooting: UEFI loses its boot configuration

If you use an EFI boot stub and configured UEFI to boot your kernel directly, after the disk is unlocked the firmware might forget all its configuration (and it loses it on every unlock). In that case you can install an UEFI boot loader to the default/fallback boot path esp/EFI/BOOT/BOOTx64.EFI and then the firmware would be able to boot it with its default configuration.

It will be helpful to have an USB flash installation medium: if you plug it in after unlocking the disk, it will auto-boot and let you configure your now-unlocked boot disk.

Using a mkinitcpio hook

Instead of using a PBA, the drive can be setup to only encrypt the root partition whilst leaving the /boot partition accessible. This way, the system can boot and a mkinitcpio hook used to unlock the drive before the rest of the boot sequence is completed. This has the advantage of not needing to install a PBA and reboot, and also allows for easier support of resume from S3 sleep.

Encrypting your drive

Follow the steps outlined above to create a rescue system, then boot into it.

Warning:

• These steps must be executed from the rescue system, or a live system with sedutil-cli installed.
• These steps will destroy all data on the drive. Make sure to have a backup before starting!

The first command will delete everything off of the drive. Omitting it will not save your data, because setting up the new locking range will destroy it anyway.

# sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID PSID DRIVE
# sedutil-cli --initialsetup PASSWORD DRIVE
# sedutil-cli --setMBREnable off PASSWORD DRIVE

The PSID code can be found on the physical hard drive (the code must be written without any spaces or underscore).

Partition the drive

Partition the drive as desired, making sure the EFI and/or /boot partitions are at the start of the disk, immediately followed by the root partition. For example:

1. 1G, FAT32, /boot
2. ext4, /

Or a slightly more complex setup:

1. 100M, FAT32, EFI
2. 2G, ext4, /boot
3. ext4, /
4. Swap

It is important the EFI and/or /boot partitions have enough space to hold all of the kernel images you may want to install. It will not be possible to expand these later without destroying all of the data in the root partition, as the encryption headers would be overwritten.

Enable locking

Use lsblk --fs to help identify the correct drive, e.g. /dev/sdx, then use lsblk --f DRIVE to find:

• RANGE_START = "Start" of the root partition
• RANGE_LENGTH = "Sectors" of the root partition

In the example below, RANGE_START would be 2097152 and RANGE_LENGTH 974675968. It is important that these numbers are divisible by 8 to work with sedutil-cli, rounding may be necessary.

Device       Start       End   Sectors   Size Type
/dev/sda1     2048   2097151   2095104  1023M EFI System
/dev/sda2  2097152 976773119 974675968 464.8G Linux filesystem

Create locking range 1 to only cover the root partition (and optionally swap):

# sedutil-cli --setupLockingRange 1 RANGE_START RANGE_LENGTH PASSWORD DRIVE
# sedutil-cli --enablelockingrange 1 PASSWORD DRIVE

Lock boot partition as read-only (optional)

For extra security, the EFI and/or /boot partitions can be locked as read-only. Identify the RANGE_START and RANGE_LENGTH in the same manner as for the root partition, then issue the following commands:

# sedutil-cli --setupLockingRange 2 RANGE_START RANGE_LENGTH PASSWORD DRIVE
# sedutil-cli --readonlyLockingRange 2 PASSWORD DRIVE

Install the operating system

Warning: Powering off the system now will cause the drive to become locked. If this happens, boot into the rescue system and use the following command to unlock the range:

# sedutil-cli --setlockingrange 1 rw PASSWORD DRIVE

Then proceed to reboot the system without powering off.

You may now install the operating system, taking care to use the existing partitions and not alter them in any way. Once done, reboot into the new system without powering off first.

Setup mkinitcpio

Custom mkinitcpio hook

Create a custom mkinitcpio hook to ask for the drive password on boot:

/etc/initcpio/install/sedutil

#!/bin/bash

help() {
    cat <<HELPEOF
Unlock OPAL drives by prompting for password
HELPEOF
}

build() {
    add_binary sedutil-cli
    add_binary clear
    add_binary find
    add_binary gawk
    add_binary grep
    add_binary readlink
    add_binary stty
    add_binary xargs
    add_binary partprobe

    add_runscript
}

The following script also contains code for unlocking the boot range, which can be uncommented if needed. Additionally, if you need to be able to resume from sleep, you may need to slightly modify the below script. See #Preparing drive for sleep for more information and caveats about S3 sleep.

/etc/initcpio/hooks/sedutil

#!/usr/bin/ash

run_hook() {
	msg  "OPAL Drives Unlock"

	for block_device in $(list_block_devices) ; do
		if ! is_opal_drive "$block_device" ; then
			continue
		fi
		opal_unlock "$block_device" "$(get_block_device_info $block_device)"
	done
	
	partprobe
}

list_block_devices() {
	for glob in 'sd[a-z]' 'nvme[0-9]n[0-9]' 'nvme[0-9][0-9]n[0-9][0-9]' ; do
		find /dev/ -name "$glob"
	done
	if [ $? != 0 ] ; then
		msg "Unable to list block devices"
	fi
}

is_opal_drive() {
	sedutil-cli --query "$1" > /dev/null 2> /dev/null
	return $?
}

get_block_device_info() {
	sedutil-cli --query "$1" | gawk '/^\//{print;exit}'
	if [ $? != 0 ] ; then
		msg "Unable to query $1"
	fi
}

opal_unlock() {
	while true ; do
		stty -echo
		echo -n "Password for $2 ($1): "
		read pass
		stty echo

		# Unlock root range for read/write
		sedutil-cli --setlockingrange 1 rw "$pass" "$1"
        # Uncomment to also unlock boot range
		# sedutil-cli --setlockingrange 2 rw "$pass" "$1"
		if [ $? != 0 ] ; then
			msg "Failed to unlock!"
			continue
		fi
        
		msg  "Unlocked!"
		break
	done
}

Custom hook in mkinitcpio config

Edit you mkinitcpio configuration to add the sedutil hook before udev. It is important the hook runs before udev, otherwise udev will get stuck trying to access the encrypted drive and cause I/O errors.

Note: It may be necessary to add the keyboard and keymap hooks to have a working keyboard on boot, together with the required kernel modules for your keyboard. See mkinitcpio/Minimal initramfs#Keyboard modules for more details.

Warning: It is a good idea to create a separate mkinitcpio config and image as described in Mkinitcpio#Customized generation, as your system may be unbootable if e.g. the keyboard does not work.

/etc/mkinitcpio.conf

HOOKS=(base keyboard keymap sedutil udev autodetect ...)

Regenerate mkinitcpio image

Finally, regenerate the initramfs.

You may now reboot your system. If all goes well, the hook will prompt for a password to unlock your drive and then proceed with the rest of the boot process. If something went wrong, you can boot into the rescue system, manually unlock the drive, then reboot into your normal system using the default initcpio image and proceed to debug your system.

Accessing the drive from a live distribution

The easiest way is to boot the encrypted SSD first, in order to run the shadow MBR. Then press the key that prompts the boot menu and boot whatever device you prefer. Such a way the SED will be completely transparent.

Another way is to directly boot into the live distribution and use sedutil to unlock the SSD:

# sedutil-cli --setlockingrange 0 rw password drive
# sedutil-cli --setmbrdone on password drive
# partprobe drive

Verify that you followed the instructions after the note in #Linux support.

Disable locking

If you want to turn off Locking and the PBA:

# sedutil-cli --disableLockingRange 0 password drive
# sedutil-cli --setMBREnable off password drive

Re-enable locking and the PBA

You can later re-enable locking and the PBA using this command sequence

# sedutil-cli --enableLockingRange 0 password drive
# sedutil-cli --setMBREnable on password drive

Encrypting a non-root drive

A secondary drive that is not used for the system root, for example a separate drive hosting a permanent /data partition or a portable USB-drive, can be setup.

A non-root drive does not require loading a PBA. So, activating the encryption is as simple as running:

# sedutil-cli --initialsetup password drive
# sedutil-cli --enableLockingRange 0 password drive

If it is a portable drive and/or you want to unlock the drive manually, you should do the as in #Accessing the drive from a live distribution, but you need just the first command, because MBR shadowing has not been enabled:

# sedutil-cli --setlockingrange 0 rw password drive

This will unlock the drive until it is disconnected or your machine goes into suspend, beware that this may cause loss of data.

Changing the passphrase

Changing the passphrase does not lose existing data on the drive, and does not require re-encryption of data.

# sedutil-cli --setSIDPassword password newpassword device
# sedutil-cli --setAdmin1Pwd password newpassword device

Read the #Key management technical implementation section above to learn about how this is implemented securely within the drive, and why it is possible to change the passphrase without losing the existing encrypted data on the drive.

Waking up from suspend

Warning: Keeping the unlock password or hash on disk and in kernel memory is a requirement.

Suspending the system results in a crash by default, because power is being cut from the drive and that causes it to lock itself. In order to wake up from suspend the kernel should know a hashed password for the disk. This functionality is in-kernel since 4.11, but it is only available via a fork of sedutil, either sedutil-sleep-git^AUR or sedutil-ladar^AUR. Note the latter has additional features but a slightly different command syntax [6].

Generate a hashed password for the block device specified as /dev/device:

# sedutil-sleep --printPasswordHash password /dev/device

Preparing drive for sleep

With mkinitcpio hook

If already using a mkinitcpio hook to unlock the drive on boot, then you can simply add code as below to the hook to also prepare the drive for sleep. Make sure this code is placed after the command that unlocks the ranges sedutil-cli --setlockingrange, otherwise it will fail. In this example, $pass is a variable containing the password for unlocking, while $1 is a variable containing the device to prepare for sleep, typically the root partition (e.g. /dev/sda1).

/etc/initcpio/hooks/sedutil

sedutil-cli --prepareForS3Sleep 1 "$pass" "$1"
if [ $? != 0 ] ; then
	msg "Prepare for S3 failed for $1"
fi

With systemd service

Create a systemd service, inserting hashes for each device:

/etc/systemd/system/sedutil-sleep.service

[Unit]
Description=sedutil-sleep

[Service]
Type=oneshot
#Add as many ExecStart lines as needed here
ExecStart=-+/usr/bin/sedutil-sleep -n -x --prepareForS3Sleep 0 hash /dev/device
#ExecStart=-+/usr/bin/sedutil-sleep -n -x --prepareForS3Sleep 0 hash2 /dev/device
RemainAfterExit=true

[Install]
WantedBy=multi-user.target

Using cryptsetup

cryptsetup can be used to perform the initial setup of OPAL equivalent to the example of sedutil, albeit not for USB-drives. cryptsetup is always used on block devices, i.e. an individual partition, and adds a LUKS header to it which includes a LUKS encrypted OPAL key to unlock it. See cryptsetup(8) § SED (SELF ENCRYPTING DRIVE) OPAL EXTENSION for details.

cryptsetup's advantage over sedutil is that, besides the initial luksFormat command, no special setup is required. It is just a LUKS device like any other which allows using all features LUKS provides and the option of using systemd-cryptenroll.

See the cryptsetup 2.7.0 release notes for command examples with OPAL related output of the LUKS header.

Note: Other TCG Security Subsystem Class standards (e.g. TCG Ruby and TCG Enterprise) are not supported since cryptsetup relies on the kernel for SED support and the kernel only supports OPAL.

Encrypting a partition

Encrypting a partition with OPAL requires the OPAL admin password. If you have not previously set one, you will need to erase all data on the drive with cryptsetup-erase(8) to be able to create a new OPAL admin password. Follow the instructions in #Secure disk erasure to perform the erase.

OPAL hardware encryption can be set up on a partition using cryptsetup-luksFormat(8) option --hw-opal-only. This will avoid the performance penalty that software encryption brings to an encrypted partition and the CPU.

Alternatively, the --hw-opal option can be used to setup both OPAL hardware encryption and dm-crypt software encryption at the same time. The default dm-crypt encryption options for LUKS2 apply and can be configured.

For example, with /dev/sdXY as the partition on a drive with OPAL support:

# cryptsetup luksFormat --hw-opal-only /dev/sdXY

WARNING!
========
This will overwrite data on /dev/sdXY irrevocably.

Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/sdXY: 
Verify passphrase: 
Enter OPAL Admin password: 
Verify passphrase:

Subsequent to the setup, the block device can be opened and formatted with a filesystem, see dm-crypt/Device encryption#Unlocking/Mapping LUKS partitions with the device mapper. Only the LUKS passphrase is required from now on, because the header automatically unlocks the OPAL encryption.

Note: If the system's EFI/BIOS itself supports and is configured for #Using Pre-boot Authorisation (PBA), it will additionally prompt for the /dev/sdXY Admin1 password subsequently.

Removing a locking range

Since OPAL locking ranges are neither readable nor writable while in a locked state, an encrypted partition cannot be repurposed until the OPAL locking range spanning it is removed.

To remove OPAL encryption from a partition use cryptsetup-erase(8):

Warning: This will erase the LUKS header (unlike when using software encryption) and remove the OPAL locking range irrecoverably removing access to the encrypted data. A backup of the LUKS header cannot be used to recover from this operation since the OPAL locking range cannot be restored to the previous state.

# cryptsetup erase -v /dev/sdXY

Enter OPAL Admin password:
Command successful.

Secure disk erasure

Whole disk erasure is very fast, and remarkably simple for a self-encrypting drive. Simply passing a cryptographic disk erasure (or crypto erase) command (after providing the correct authentication credentials) will have the drive self-generate a new random data encryption key internally. This will permanently discard the old key, thus rendering the encrypted data irrevocably un-decryptable. The drive will now be in a 'new drive' state.

Read the #Key management technical implementation section above to learn more about how this is implemented securely within the drive.

The Solid state drive/Memory cell clearing article covers comprehensive guides to perform the erasure securely.

Warning: The following command will erase all data on the drive, even if it is run only against a partition.

The following shows an example output by using cryptsetup-erase(8) to perform it:

# cryptsetup erase -v --hw-opal-factory-reset /dev/sdX

Enter OPAL PSID: 

WARNING!
========
WARNING: WHOLE disk will be factory reset and all data will be lost! Continue?

Are you sure? (Type 'yes' in capital letters): YES
Command successful.

The -v option returns the Command successful output.

Tip:

• For NVMe drives use the namespace form of the device name, i.e. use /dev/nvmeXnY rather than /dev/nvmeX.
• Check that your drive is using the optimal logical sector size before performing the erase.
• Omit any dashes when entering the PSID.

BIOS based ATA-password

Previous to the industry's TCG OPAL 2.0 standard initiative, the relevant ATA standard defined an "ATA security feature set" for full-disk encryption using self-encrypting drives. This relies on the PC BIOS, not the drive, to feature an unlocking mechanism utilizing the BIOS to setup the user's encryption passphrase. This legacy BIOS-based (ATA) method was considered more unreliable to setup and prone to error with regard to interoperability between PC vendors.[7] Typical errors include, for example, inabilities to unlock a device once it is plugged into a system from a different hardware vendor. Hence, the availability of BIOS support for the legacy password mechanism decreases in availability, particularly for consumer hardware.

See Solid state drive#Security for more information.

See also

• sedutil (github)
• sedutil official docs
• sedutil-cli commands usage
• sedutil-sleep