Self-encrypting drives

Related articles

• Data-at-rest encryption
• Trusted Platform Module

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 2.0 and Enterprise standards developed by the Trusted Computing Group (TCG). Enterprise SAS versions of the TCG standard are called "TCG Enterprise" drives. 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.

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

• 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.[1]

• 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".[2] 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.[3] 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

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."

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 OS 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.

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.

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:

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

Windows version of sedutils output:

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

Download (or create) the pre-boot authorization (PBA) image

Download the pre-boot authorization (PBA) image for a BIOS or UEFI machine provided by the Drive Trust Alliance.

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

Alternatively, you can create your own PBA image using the supplied helpers:

# mklinuxpba-efi

to create an EFI image (/boot/linuxpba-efi.diskimg) and

# mklinuxpba-bios

to create a BIOS image (/boot/linuxpba.diskimg).

Test the PBA on your machine (optional)

Refer to the official docs.

Do not expect to get a list of your OPAL disks. If you try the PBA from a USB stick and your SSD disk is still not activated for OPAL locking (as it is recommended before the PBA has been successfully tested) you will get an error message including "INVALID PARAMETER" (see this issue). But this shows that the PBA is actually working and finding your disk. The Wiki is outdated in this regard.

Prepare and test the rescue image (optional)

Refer to the official docs.

Set up the drive

Decompress the PBA (if required):

$ gunzip pba.img.gz

Use the output of lsblk --fs to help identify the correct drive.

# sedutil-cli --initialsetup password drive
# sedutil-cli --loadPBAimage password pba_file drive
# sedutil-cli --setMBREnable on password drive

Enable locking

# sedutil-cli --enableLockingRange 0 password 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 OS.

Accessing the drive from a live distro

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 distro and use sedutil to unlock the SSD:

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

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.

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 --setMBRDone on password drive
# sedutil-cli --setMBREnable on password drive

Encrypting a non-root drive

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

# sedutil-cli --initialsetup password drive

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 in it's only available via a fork of sedutil, sedutil-sleep-git^AUR.

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

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

Then 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

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.

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.[5] 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