Use the hardware-based full disk encryption of your TCG Opal SSD with msed

(This post has been updated since initial publication, see last section for details.)

Introduction

My blog post on usable hardware-based SSD encryption has seen a great deal of activity. Although that post dealt primarily with the ATA security based type of hardware-based full drive encryption, readers from all over joined the discussion in the comments to talk about an increasing number of new self-encrypting drives supporting the TCG Opal standard.

msed_pba_bootup.jpg

Up until recently, configuring these TCG Opal drives was only possible under Windows, or under Linux with a commercial solution that was not available to mere end-users. Fortunately, a programmer named r0m30 stepped up to the challenge and has developed an open source utility called msed and an accompanying pre-boot authorization (PBA) image with which the super fast encryption function on these drives can be fully configured and used also in pure Linux systems.

This post summarises how I built, configured and installed msed and its PBA on my Ubuntu 14.04.1 machine with its Samsung 850 PRO 512G TCG Opal-compliant SSD.

How does TCG Opal drive encryption work?

Many modern SSDs perform transparent AES encryption on all written data in hardware. One advantage of this approach is that the whole drive can be secure erased by simply generating a new set of encryption keys. Another advantage is that users can have all of their data fully encrypted at rest without any performance hit whatsoever. Also, third-party software-based drive encryption negatively affects SSD performance and longevity, for the largest part because this data is basically incompressible when it hits the drive.

TCG Opal is a new standard for communicating with supporting drives concerning their encryption functionality. Furthermore, it includes a really elegant way to have the user supply their authorization credentials.

In its default state, the main disc area is completely locked and inaccessible. However, when the system is booted, the encrypted disc exposes a fake disc from its firmware, called the shadow MBR (master boot record), 128MB in size. Usually this shadow MBR is flashed with the pre-boot authorization (PBA) image, which is in essence a small operating system (including MBR, boot sector, filesystem) that asks the user for their drive password, which it then communicates to the disc via OPAL commands. If the password is valid, the disc unlocks itself, and then the real operating system is loaded up.

This white paper by HP contains an explanation of the provisioning and boot process on page 5. To summarise: Once correctly configured, a system with such an OPAL-compliant disc will request the drive password at boot. The drive will only unlock and decrypt if the correct password is supplied.

Building msed and its PBA image from source

r0m30 programmed a suitable PBA image based on the syslinux open source, and a utility called msed for the provisioning (setting password, writing PBA image) of OPAL drives.

Because this software performs a security critical function, I reviewed as much as possible of the source code in syslinux/com32/msedpba (the Opal-specific part of the PBA) and of the whole msed utility, including the script that builds the PBA image. (I also spent some hours disassembling the binary PBA image.)

After this mini review, it was of course preferable to build and use my own binaries.

To build both the PBA image and msed from source, I did the following:

# I retrieved these sources on Tuesday 2015-02-10
git clone https://github.com/r0m30/msed.git
git clone https://github.com/r0m30/syslinux
cd syslinux
# make clean is going to fail trying to get the EFI submodule. ignore.
make clean
make bios
cd ../msed/image
sudo ./buildbiospba
# remember the location of the resultant .img file!
gunzip biospba-0.20beta.img.gz
# now let's build msed itself
cd ..
# I'm on x86_64, adapt to your own architecture!
make CONF=Release_x86_64
# copy the image to the same location as the msed binary
cp image/biospba-020beta.img .

Stripping the msed binary at top-level, I found an md5sum-identical binary to the 0.20.0 one that I downloaded from r0m30’s site:

cpbotha@meepz97:~/build/msed/msed/dist/Release_x86_64$ md5sum msed 
3a22c344ecbfa15b43ae7764341060ab  msed

Installing the msed PBA

This is very important: I’ve configured my BIOS to boot in legacy mode, i.e. NOT UEFI. The msed documentation also states that this is necessary. It also makes sense, because the PBA image is a legacy boot image!

msed needs libata.allow_tpm to be configured for the running kernel. I edited /etc/default/grub so it looked like this:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash libata.allow_tpm=1"

… after which I did update-grub and then rebooted. After reboot, msed --scan gave me sensible output.

It was now time to configure the drive for encryption. I found this quite stressful; I’ve had near-bricking experiences with expensive Intel 520 SSDs during some of my previous ATA security experiments with flakey BIOS implementations (Insyde H20, what a mess). In any case, I followed this procedure:

# set the drive password: mine is long, but no spaces, no special chars
./msed --initialsetup mylongpassword /dev/sda
# write the PBA into the shadow MBR
./msed --loadPBAimage mylongpassword biospba-0.20.img /dev/sda
# activate the shadow MBR
./msed --setMBREnable on mylongpassword /dev/sda
# activate drive locking
./msed --enableLockingRange 0 mylongpassword /dev/sda

After this, I switched the machine off, and on again. Lo and behold! I was prompted for my OPAL password at bootup, and could let myself in.

To test, I booted up the machine with a Linux Live USB. In place of the encrypted disk I could only see the shadow MBR.

Conclusion

TCG Opal is a great way of using your SSD’s hardware-based full disc encryption. I am very grateful to r0m30 for creating msed and its PBA image: These are crucially important open source tools for working with Opal discs.

Updates to this post

June 9, 2016

Fixed missing “of” in title. Thanks adutoit!

After adding a 500G Samsung 850 EVO to the 850 PRO already in my desktop machine, the BIOSPBA was not able to unlock both drives. However, after a quick upgrade to the LinuxPBA using the same procedure as documented in this post, both drives unlock after correct password entry. As an added bonus, with the BIOS on this machine set to Legacy+UEFI, I legacy boot into the PBA, enter my password, have both drives unlock, and then automatically UEFI boot to any of the operating systems on the GPT partitions of the unlocked drives.

SSDs with usable built-in hardware-based full disk encryption

(tl;dr / post summary: Many current SSDs do super fast hardware AES encryption, but only a very few expose this correctly to the user, meaning you often still need a third-party software solution. Information on this is incredibly hard to find.)

Imagine that your laptop or your PC gets stolen. That would be terrible. However, it would be even worse if your laptop contained confidential data, either your own or that of your employer or client. It’s clear that encrypting one’s hard drive has become a necessity. There are good open source software solutions for this, for example TrueCrypt (Windows, Linux and OSX) and the LUKS/dm-crypt system. However, such software encryption systems require a small chunk of your CPU capacity, and also affect SSD performance and durability to a lesser or greater extent, depending on the controller.

Intel 520 self-encrypting SSD. Image courtesy of Anand Tech.
Intel 520 self-encrypting SSD. Image courtesy of Anand Tech.

A number of SSD drives now implement real-time AES encryption in hardware. Usually the reason for this is to enable fast secure erase: When the AES keys are destroyed by the firmware, a very cheap operation that requires almost no writing to the flash, no data on the whole SSD can be read, and can thus the data can be considered securely erased. The encryption and decryption take place in the controller hardware, so there is no performance hit. The Sandforce SF2281 controller is one of the more well-known SSD controllers that does this. In some cases, the manufacterer uses the HDD password or ATA password (configurable via many laptop BIOSes, very few desktop BIOSes, or the ATASX BIOS extension) to encrypt the AES keys. This means that even if the manufacturer got hold of your drive, and you had set a strong ATA password, they would probably never be able to decrypt your data. I call this usable built-in-hardware-based full disk encryption. In these cases, you do NOT need to install third-party software full disk encryption, and can enjoy the full performance of your SSD. In many other cases, the encryption keys are stored in the drive firmware, but are NOT explicitly encrypted with a user-supplied password. This is non-usable encryption, because in theory the manufacturer or a sufficiently skilled hardware hacker can extract the encryption keys from the drive firmware and decrypt all of your data. In these cases, you ABSOLUTELY have to use a third-party software disk encryption software tool. The purpose of this post is to keep a list of current SSDs with usable and non-usable built-in hardware-based full disk encryption. Whilst recently shopping for a suitable SSD, this information was unreasonably hard to come by, hence this list. If you have additions or corrections, please let me know in the comments.

SSDs with USABLE built-in encryption:

Intel 320

This post and this post by an Intel representative confirm that the AES keys on the Intel 320 SSD are encrypted with the user’s ATA password. The second gives more detail on the implementation details, for example that the ATA password itself is also stored in non-reversible hashed form in the drive firmware. The white paper linked to under the Intel 520 heading below confirms the working of the 320 encryption setup.

Intel 520

This is the first Intel SSD making use of the Sandforce SF-2281 controller. Due to a bug in the controller, the drive does AES-128 encryption (instead of the advertised AES-256). AES-128 is still considered to be sufficient for most purposes. After two unsuccessful attempts getting a clear answer on the details of the Intel 520 encryption directly from Intel support, I finally stumbled on this white paper by Intel: Managing Intel Solid-State Drives Using Intel vPro Technology (mirror here). On page 3, in the grey box at the bottom of the page, we see the following text (bold words by me):

How Self-encrypting drives (SEDs) Work: SEDs, such as the Intel® SSD 320 Series and Intel® SSD 520 Series, have a drive controller that automatically encrypts all data to the drive and decrypts all the data from the drive. The disk encryption key is never present in the computer’s processor or memory, where it could be accessed by hackers. The key used to encrypt and decrypt is securely stored only on the drive. Because the disk encryption key is encrypted with the ATA (Advanced Technology Attachment) passwords, the key is made accessible to the drive only after successful user authentication; without the key the data remains encrypted on the media. Authentication of the user is done within the SED by supplying the ATA user password, which is isolated from the OS. Therefore, attacks on OS vulnerabilities cannot affect an SED’s pre-boot process.

That’s a pretty conclusive statement by Intel that both the 320 and the 520 encrypt their AES encryption key with the user-supplied ATA password. After a few weeks and some mails with Intel tech support, I also received the following confirmation concerning the Intel 520 SSD:

Yes, ATA password is used to encrypt the encryption keys stores on the SSD. In other words: The Encryption Keys depends on the ATA password to decrypt them. The ATA password is not used in combination with the Encryption Keys to encrypt the data.

Intel support furthermore confirmed that the Intel 520 is compliant with FIPS-197.

SSDs with PERHAPS USABLE built-in encryption

In these cases there are indications that the mentioned drives are encrypting the encryption keys with the ATA user password, but I have not been able to find more conclusive confirmation. If you find anything, please let me know it the comments, because eventually I’d like to move them out to the list of USABLE or NON-USABLE encryption.

Plextor M5 Pro

On the product page the graphic shows quite clearly that ata passwords are related to encryption keys, but it does not specify in which way these are linked. A reasonable approach would of course be that the key is encrypted with the ATA password, but until that’s confirmed, this drive remains on the “perhaps”-list.

Samsung 840 Pro

Again it’s far too hard to find conclusive information on the encryption implementation. On this product page, we find the following text:

Keep your data safe with Self-Encrypting Drive (SED) Technology Simply enable an HDD password via your computer’s BIOS, and Samsung’s SSD 840 applies data encryption automatically.

This is not as conclusive as I’d like, but there is an implication that there’s a link between the HDD password and the encryption on the Samsung.

Samsung PM830

This drive is not to be confused with the consumer-oriented Samsung 830. The PM830 is a special professional OEM version, found for example in Dell Latitude laptops. There are indications, such as this great 2012 overview paper, titled Hardware-based Full Disk Encryption (In)Security Survey, by Tilo Muller, Tobias Latzo, and Felix C. Freiling (accompanying website with demonstration videos), which mention the PM830 as an example of hardware-based full disk encryption. I’m still searching for the cited spec document that might confirm whether the PM830 encrypts its AES-256 keys with the ATA password, and also the possible password-length limitations.

SSDs with NON-USABLE built-in encryption

OCZ Agility / Vertex 2 / 3 / 4

In this posting on the OCZ Technology Forum, we see that in at least some of the OCZ SSDs, “The encryption key is not directly linked to the ATA Security password (or the BIOS password).” I have not been able to find more specific information about other OCZ offerings. However, my expectations are not very high based on this previous work by OCZ.

Conclusion

  1. Manufacturers of SSDs with built-in encryption are doing an absolutely TERRIBLE job of informing their customers of their specific encryption implementations. For something as critical as full disk encryption, I would expect full disclosure. If the encryption approach is good, disclosing its details won’t affect its security.
  2. The only SSDs that I’d recommend in terms of usable built-in disk encryption are the Intel 320 and 520 drives. It would be great if this list could be expanded. If you have a direct connection to the relevant persons at the various manufacturers, please make use of this and let me know of the results so I can update this blog post.
  3. Your BIOS has to support the full 32 character ATA password specification. The Samsung laptop I’m typing this on only supports 8  character ATA passwords, so I’d think carefully about installing a hardware-based encrypted SSD in here. My desktop with the Intel 520 SSD has the ATASX bios extension and supports up to the full 32 characters. When you buy a new laptop or motherboard, make sure it has a good ATA security extensions implementation, supporting the full 32 characters.
  4. Although ideally the built-in hardware encryption would be usable and secure, the disappointing state of affairs leads me to the conclusion that a good option at this point is still to select an SSD that is impacted as little as possible by the software encryption (avoid the Sandforce controllers, or any other controllers that make use of hardware compression), and then use a solution such as TrueCrypt or luks/dm-crypt (even for a non-Sandforce controller such as on the OCZ Vertex 4, the negative impact is significant, unfortunately). For my next SSD purchase, I will again compare the super-fast hardware encryption of the Intel 520 vs. SSDs that are able to cope to some extent with software encryption, although I am currently leaning towards the Intel 520.

Other resources

  • I’ve written another post documenting my successful experience with r0m30’s open source TCG Opal configuration utility and PBA image.
  • Vincent Tenniglo sent in this article by AnandTech where Anand himself experiments with the TCP Opal 2.0 compliant Crucial M500 and the Windows 8 eDrive support. In theory, with eDrive-compatible drives (meaning Opal 2.0), Windows BitLocker makes use of the drive’s hardware encryption. Ed: Because this is Windows closed-source, we are unfortunately even less sure of what’s happening behind the scenes. It’s an interesting development nonetheless.
  • Great 2012 overview paper, titled Hardware-based Full Disk Encryption (In)Security Survey, by Tilo Muller, Tobias Latzo, and Felix C. Freiling. Also see the accompanying website with demonstration videos.

Updates

  • 2015-02-11: Added link to my msed, PBA and Opal post.
  • 2014-07-02: Updated with AnandTech Opal 2.0 Windows eDrive Crucial M500 article submitted by Vincent Tenniglo.
  • 2013-02-08: Updated with confirmation by Intel tech support concerning the Intel 520.
  • 2013-01-15: Updated link to Muller et al. overview paper.
  • 2012-12-23: Added the Samsung PM830 to the “perhaps” list (thank you Pieter Kitslaar), and linked to great hardware-based full disk encryption overview paper.