Self Encrypting Drives



Many SSDs are also Self Encrypting Drives (SEDs) they just need a few bits flipped to make them work. As the SSDs use encryption under the hood anyway there’s no performance overhead.


This is something of an almanac post after a couple of days of prodding around the topic of PC device encryption. I wanted to make sure that the PCs I use for work stuff were properly protected, but I also wanted to minimise the impact on performance.


As my laptop runs Windows 8.1 it seemed obvious to check out BitLocker, but a quick search revealed that software based BitLocker has some degree of performance overhead.

In the end I actually went with BitLocker on my laptop, as the SanDisk X300 SSD I have isn’t a SED (as it doesn’t support Opal or Microsoft eDrive), which is a shame as the article I found on the X300s gives a pretty good review of what’s out there.

Even if I did have an X300s rather than a plain old X300 the eDrive/BitLocker combination wouldn’t have been easy, as it requires doing a clean install of Windows rather than letting you keep your existing setup.


SSDs use encryption internally anyway so that the blocks written to flash memory don’t have long runs of 1s or 0s, so it’s almost trivial for an SSD to also be a SED – all that’s needed is a means to manage the keys that are used to unlock that encryption. Out of the box SEDs are like safes with the door open and no combination set – they just need some tools to set the lock.

Class 0

With my desktop machine (a NUC) I’ve got a Samsung SSD that supports three different modes of encryption:


  • Encrypted Drive is eDrive/BitLocker – too much trouble to configure
  • More on Trusted Computing Group (TCG) Opal below
  • Class 0 just uses a BIOS boot password. After reading this piece on Class 0 I decided it was probably worse than useless.

Opal and sedutil

The X300s article had run through the basics of Opal and use of the Wave Embassy app to enable it. Sadly as I have just a plain X300 I wasn’t getting a free license for that. There are a bunch of commercial offerings for Opal, from the usual suspects, and frankly they all look awful.

Open Source to the rescue… the Drive Trust Alliance offers sedutil for Windows and Linux. It’s a combination of a command line tool to configure Opal, and a Linux based pre boot application (PBA) to ask for the password that unlocks your drive.

After a bit of downloading and testing I confirmed that I was good to go, and following the encrypting your drive instructions worked perfectly.

The user experience

Most of the time the encryption is totally seamless in terms of performance and use experience. The only change is at boot (or resume from hibernation) when the PBA is launched first and asks for a password – the system then unlocks the SSD and reboots into the normal OS.

No Sleep

The one issue seems to be that the system will no longer make use of sleep mode, instead dropping into hibernate (to force a request for the password for resume). I can see why that’s more secure, but for my own use case I’d be happy to have sleep/wake without being asked for a drive password.


I wish the drive in my laptop was a SED. The BitLocker performance overhead isn’t too annoying, and it didn’t even take too long to encrypt the whole SSD, but it’s still sub optimal.

Using open source tools with the SED in my desktop was quick and easy. So if I’m even unlucky enough to be burgled I won’t have to worry about the data on that device.

One Response to “Self Encrypting Drives”

  1. 1 Tyrone

    The Tom’s hardware post that you link to written by drtweak is so bad that to quote Nobel Prize winning Physicist Wolfgang Pauli, “This isn’t right. This isn’t even wrong.”

    In a Class 0 SED, when the drive was first initialized, it generated an encryption key used fro the AES encryption of everything going to & from the drive. That key is always internal to the SED. When the drive was locked with a BIO hard drive password, there’s a whole bunch of stuff that happens with what are called scan codes & the internal key, but the net effect is the drive isn’t accessible and drtweaks description of defeating it with a BIOS admin password does not work. drtweak should have tried it before shooting off his mouth. His post gets a high rank on Goolge, not becuase he’s right, but because he’s so so wrong..

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: