Requisitos técnicos

Self-encrypting drives (SEDs) are a form of full-disk encryption (FDE). Unlike software-based FDE (TrueCrypt, FileVault, LUKS, and so on) where the OS manages the encryption, SEDs have encryption capabilities built directly into the drive electronics and firmware. SEDs are OS agnostic and are based on vendor-independent standards. The international body respon-sible for defining the standard is the Trusted Computing Group (TCG;

http:// www.trustedcomputinggroup.org/ ). The standard is the TCG Storage Security Subsystem Class: Opal, Specification Version 2.00.

This section identifies drives with Opal encryption and describes how appropriate keys can be used to unlock the drive. The recovery of encryp-tion keys is outside the scope of this book. The examples shown here assume the key is known.

A physical examination of the drive can already indicate if it is an Opal SED. The existence of a Physical Secure ID (PSID) string printed on the label of the drive is shown in Figure 5-2. This string is used for the Opal RevertSP feature, which generates a new key securely, destroying all data and resetting the drive to its original factory state. The PSID cannot be queried from the drive and must be physically read or scanned if a QR code exists. The exis-tence of a PSID string does not mean the drive is locked and passwords are set; it just indicates the drive supports Opal full-disk encryption.

Figure 5-2: Opal SED PSID

Full-disk encryption has a chicken-and-egg problem. If an entire drive is encrypted, including the boot sector, how can the system execute the master boot record (MBR) and ask for a password or other security credentials?

The solution was to implement a shadow MBR and store it in the system area of a disk (the same place where SMART data, bad block lists, and so on are stored). When an Opal disk is in a locked state, only the shadow MBR is visible to the host. It is a group of unencrypted sectors (can be large—

150MB in size, for example) that is executed as a normal MBR (the host is completely unaware that it is using a shadow MBR). This alternate boot area can execute code to request a password, access a Trusted Platform Module (TPM) chip or smartcard, or get other credentials. Once the disk has been unlocked, the proper MBR becomes visible, and a normal boot process can begin.

An open source command line tool was created to manage Opal SED encryption under Linux. Originally called msed, it was available at https:// github.com/ r0m30/ msed/ , but the tool was recently renamed sedutil-cli and moved to https:// github.com/ Drive-Trust-Alliance/ sedutil/ . This tool is still under development and may not work on all drives. Follow the instructions carefully and ensure thatlibata.allow_tpmis enabled in the kernel.

The following command scans the local system for all Opal-compliant SED drives. Out of four attached drives, one disk is detected as Opal ver-sion 2:

# sedutil-cli --scan

Scanning for Opal compliant disks

/dev/sda 2 Crucial_CT250MX200SSD1 MU01 /dev/sdb No WDC WD20EZRX-00D8PB0 80.00A80

/dev/sdc No INTEL SSDSA2CW300G3 4PC10302

/dev/sdd No Kingston SHPM2280P2H/240G OC34L5TA No more disks present ending scan

You can query the drive to find information about the Opal status, including if a disk is encrypted, locked, or has a shadow MBR (all three are shown in this example):

# sedutil-cli --query /dev/sda

/dev/sda ATA Crucial_CT250MX200SSD1 MU01 15030E69A241

...

Locking function (0x0002)

Locked = Y, LockingEnabled = Y, LockingSupported = Y, MBRDone = N, MBREnabled = Y, MediaEncrypt = Y

...

Two commands can be issued: one to disable locking and the second to inform the disk that the shadow MBR is not needed (MBR is “Done”). In this example, xxmonkey is the password:

# sedutil-cli --disableLockingRange 0 xxmonkey /dev/sda - 16:33:34.480 INFO: LockingRange0 disabled

# sedutil-cli --setMBRDone on xxmonkey /dev/sda - 16:33:54.341 INFO: MBRDone set on

At this point, a kernel message (dmesg) might show a change in avail-able devices. The status in this example now shows the following:

# sedutil-cli --query /dev/sda

/dev/sda ATA Crucial_CT250MX200SSD1 MU01 15030E69A241

...

Locking function (0x0002)

Locked = N, LockingEnabled = Y, LockingSupported = Y, MBRDone = Y, MBREnabled = Y, MediaEncrypt = Y

...

The drive is no longer locked, and the shadow MBR is no longer visible.

The proper MBR and the rest of the decrypted disk are available, and they can be accessed with regular forensic tools. Now the partition table of a Linux installation becomes visible, as shown in this example:

# mmls /dev/sda DOS Partition Table Offset Sector: 0

Units are in 512-byte sectors

Slot Start End Length Description

00: Meta 0000000000 0000000000 0000000001 Primary Table (#0) 01: --- 0000000000 0000002047 0000002048 Unallocated 02: 00:00 0000002048 0471887871 0471885824 Linux (0x83) 03: --- 0471887872 0471889919 0000002048 Unallocated 04: Meta 0471889918 0488396799 0016506882 DOS Extended (0x05) 05: Meta 0471889918 0471889918 0000000001 Extended Table (#1)

06: 01:00 0471889920 0488396799 0016506880 Linux Swap / Solaris x86 (0x82) 07: --- 0488396800 0488397167 0000000368 Unallocated

A locked drive that has no shadow MBR enabled will produce multiple error messages in the kernel dmesg output.

The simple example described in this section was provided for illustra-tion purposes only. Some Opal disks may behave differently with this tool.

In real scenarios, the key might not be a simple password but instead be tied to the TPM or some other enterprise security mechanism. If the wrong commands are given in this situation, the data on the disk can be irrevocably destroyed (in an instant if the key is destroyed).

From a forensics perspective, it may be useful to image the shadow MBR for analysis as well. It could contain interesting artifacts from the time the disk encryption was set up. It is also conceivable that data could be hidden in the shadow MBR region of Opal-capable drives.