Self Encrypting Drives
TL;DR
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.
Background
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.
Bitlocker
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.
SEDs
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.
Conclusion
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.
Filed under: security | 3 Comments
Tags: BitLocker, eDrive, encryption, Opal, sed, ssd, TCG
Subscribe
Recent Comments
Tim Coote on Ross Anderson RIP iain on Skiing in Espace Killy (Val… Chris Swan on Getting more from a British Ga… Murray Cowell on Getting more from a British Ga… JL on AI MacGuffin 
Pinboard.in bookmarks- Subaru battery drain due to missing 3G network
- Paying maintainers: the HOWTO
- SARS-CoV-2 airborne infection probability estimated by using indoor carbon dioxide | Environmental Science and Pollution Research
- An unbiased evaluation of environment management and packaging tools
- Computer says no: British judge refuses to cancel divorce resulting from computer mistake
- Philosophy Museum
- Royal Navy offer must improve to attract and retain staff – you can't motivate an empty chair
- New Lattice Cryptanalytic Technique
- Vortex RISC-V GPGPU
- Quantum Algorithms for Lattice Problems
Chris Swan's Weblog 
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..
Right On Tyrone. I spoke to a Samsung Tech today who told me that in addition to the HDD password, the SSD also stores an identifier unique to the BIOS/System where the password for the SSD was first set. So only using an Admin/Supervisor password to get into the BIOS on the original PC can you change the HDD password. I’m unable to verify this, but I do know that you still need the existing HDD password in order to change or clear the password and still be able to access the unencrypted data on the drive, even if you are in the BIOS as an Admin or Supervisor. For example, on Dell BIOSes, and likely others, even if you are signed into the BIOS using an Admin/Supervisor password, you can’t change or clear the HDD password without first entering the existing HDD password. Even if you clear the password outside of the BIOS, which I’m pretty sure you can do with the Samsung Magician software on Samsung SSDs, then you are left with encrypted data on the drive and no way to decrypt it. But at that point, you could re-use the drive unencrypted, or by setting a new HDD password and putting new data on it. You would only clear the HDD password using the Magician software if you unfortunately lost the password and wanted to re-use the drive while understanding that the existing data would be lost. If anyone has any better information than this, please respond.
There are slides from CCC give some insight about Class 0 and TCG Opal: https://media.ccc.de/v/35c3-9671-self-encrypting_deception
For Class 0, there are different configurations and implementations. Bottomline is: when you set it up correctly and your drive doesn’t have firmware flaws in that regard, you’re just around as safe as other encryption mechanisms.
To be more precise: “MASTER PASSWORD CAPABILITY” should be set to “Maximum”, rather than the default “High”. Also, the Master and User password should be manually set, so there are no factory defaults.
Pros of Class 0 is: as long as your hardware supports it, it’s easy to setup, doesn’t require extra tools, has no performance penalty, can be enabled / disabled in an instant and it’s OS-independent.
Cons: no BitLocker-like auto-unlock using TPM, S3 sleep is a “threat”, password prompt looks fugly on my machine (BIOS-style), black-box implementation.
For me personally, it’s BitLocker for Windows and Class 0 for Linux. TCG Opal is just a pain to setup.