Article Thumbnail

Introduction to Self-Encrypting Drives (SED)

Written on April 30, 2014 by Matt Bach
Share:
Table of Contents:
  1. Introduction
  2. What is SED Encryption?
  3. Downsides of SED encryption
  4. What is needed for SED encryption to work?
  5. Managing SED encryption passwords
  6. Conclusion

Introduction

A SED (or Self-Encrypting Drive) is a type of hard drive that automatically and continuously encrypts the data on the drive without any user interaction. What may surprise many readers is that a decent potion of the drives currently in the market (including the Samsung 840 Pro SSDs we use in our systems) are, in fact, SEDs. But since manufactures do not often tout it as a major feature, it often gets lost in the large number of typically more important specifications. Even once you purchase, install, and start using one of these SED drives, the encryption is so transparent to the user that it is unlikely they would ever realize the drive is a SED.

This encryption process is done through the use of a unique and random Data Encryption Key (DEK) which the drive uses to both encrypt and decrypt the data. Whenever data is written to the drive, it first gets encrypted according to the DEK. Similarly, whenever data is read from the drive, it first gets decrypted by the same DEK before being sent to the rest of the system.

This means that all the data on the drive is encrypted at all times. One neat trick that can be done based on this is to almost instantly and completely wipe a hard drive. All you need to do is tell the SED to generate a new DEK and all the data on the drive immediately becomes gibberish (since the key needed to decrypt the data no longer exists) and is effectively unretrievable. So if you need to quickly and securely wipe a drive before either redeployment or disposal, SEDs offer a quick and very secure way to do so. This act is called a number of different names depending on the manufacturer, although it is most often referred to as doing a "Secure Erase".

What is SED Encryption?

While having the data encrypt and decrypt automatically on a hard drive is neat, it isn't really all that useful on its own since the hard drive will automatically decrypt the data on request. However, SEDs also allow you to set what is called an Authentication Key (AK) which acts as a password that locks the drive until the key is entered. If an Authentication Key is set up, the system will prompt for the key when it first powers on. While the number of attempts varies by the motherboard, if you put in the incorrect password after three or four attempts, the system will simply keep the drive locked and continue the boot process. If that happens, the drive becomes completely unusable by the system until the computer is powered off and the correct key is entered.

Password is prompted during the POST process If you enter the wrong password 3 or 4 times
in a row, the drive remains locked


In fact, even if you remove it from the original computer and plug it into a different computer the drive will still require the AK to be entered in order for the drive to unlock. However, if you you plug it into a system that does not support SED encryption, the drive will be unusable. Since the motherboard does not have the ability to enter the Authentication Key, the drive never knows to unlock itself. The result is that the drive will remaining locked with no way to unlock it. Unless you move the drive to a system that supports SED encryption, there is no way to retrieve the data on that drive.

According to Seagate, this method of encryption has been certified by both the NIST and CSE as meeting the requirements for level 2 security for cryptographic modules.

Downsides of SED encryption

When data security is a goal, it is essential to know the limitations and drawbacks of a certain technology. SEDs are a great technology, but they are no different than anything else in that they certainly have downsides. In the case of SEDs, the main downside is that once the drive has been unlocked, it remains so until the power to the drive has been cut. In other words, if you simply reboot the computer or put it into sleep, the drive remains unlocked. It is not until you completely power off the computer that it will again require the Authentication Key to be entered.

In other words, if your laptop is stolen and it was only in sleep mode then the data on the drive is completely exposed. If you have a user password set on the OS, a thief could still simply restart the machine, boot into a live environment, and have almost full access to your data. In fact, even if you have both an OS password and a BIOS password set, the data still could be accessed by moving the drive to a different computer without cutting the power. In laptops this would be tricky (but not impossible) but on a desktop is actually rather easy with the right setup.

So if you do decide to use SED encryption, our biggest advice is to get into the habit of powering off your system when it is not in use rather than simply putting it to sleep.

A second downside to SED encryption is that it will only work in simple disk configurations. You can have multiple drives in one system with SED encryption enabled and even use software RAID, but doing something like hardware-level RAID is simply not supported.

What is needed for SED encryption to work?

Something we discovered when we decided to start offering SED encryption on our systems is that full support for SED is actually very poor. There are plenty of hard drive and SSD models that support SED encryption (although finding those models can be difficult), but full support for SED also requires a compatible motherboard.

Some features of SED (like the automatic encryption and decryption of data and Secure Erase) will work regardless of the motherboard. But if you want to use SED encryption by setting an Authentication Key, you need a motherboard that supports doing so. 
 
What we have found is that many laptops (including all the laptops in our Traverse and Traverse Pro lines) have the ability to use an Authentication Key without any need for a custom BIOS. However, they often lack the ability to set the AK though the BIOS. Of course, this doesn't mean that every laptop will support SED encryption, but in our experience laptops in general are much more likely to support it than desktop or server motherboards.
 
While talking with Asus, Super Micro, and Samsung, we have discovered that most desktop and server motherboards do fully support SEDs, but the ability to use an Authentication Key is expressly disabled. The reason for this appears to be that manufactures are afraid that a user may accidentally lock their hard drive and not remember what they used for the Authentication Key. So rather than risk having an angry customer that accidentally locked their drives, they leave that specific feature of SEDs disabled. However, since the feature is there and simply disabled, we have had success with getting custom BIOS files from the manufacturer that unlocked the ability to use Authentication Keys.

Managing SED encryption passwords

On a motherboard that fully supports SED encryption, there is a chance that there is an option in the BIOS setup to set, change, or remove the SED Authentication Key on your SED drive. However, we have found that many motherboards that support SED do not have this capability built into the BIOS. In those cases, you could use software like Winmagic to manage the SED encryption key, or you can go through a series of steps using a Linux live environment to manage the SED Authentication Key without the need for paid software.

If you have a computer purchased from Puget Systems, the System's Tools Disc that is included with your computer includes an Ubuntu live environment that has everything you need. To start this process, insert the Tools Disc into your computer and restart the system. When you see text similar to "Press any key to boot from DVD", press the space bar to boot to the Tools Disc. Once the main menu comes up, select "Live Linux Environment (Safe Graphics)" and hit enter. If you do not have a system purchased from Puget Systems, you can follow the directions from Ubuntu on how to create a LiveCD that should include everything you will need.

Once your system has booted into the Linux live environment, there are three combinations of steps you must go through in order to either set, remove, or change the SED encryption password.

  • No matter what you want to do, you must first locate the drive that you want to manage the SED encryption password on and unfreeze it.
  • Next, if you want to change the SED encryption password or remove SED encryption entirely, you need to disable SED encryption.
  • Finally, you need to enable SED encryption with a new password if you are either changing the SED encryption password or setting a new SED encryption password.
Locating and unfreezing the drive  
Step 1:
Open a terminal from the unity toolbar or with the hotkey combination "ctrl+T".

Step 2:
Enable root privileges by entering the command 'su'. You will be prompted for a password. If you are using a Puget Systems Tools Disc, enter "Password1".

 

Step 3:
Enter the command "lsblk" which will output a list of the drives that are in the system. Locate the name of the drive (sda, sdb, etc.) that you want to change the encryption password or disable SED encryption on.
Step 4:
Enter the command "hdparm -I /dev/X" where X is the drive name (sda, sdb, etc.) to check the current status of the drive. Be sure to use "-I" which is an uppercase i, not a one or lowercase L. Check to make sure that there is a line that says "enabled". If that line instead says "not enabled", then SED encryption is not currently enabled on that drive. Either SED encryption was never configured, or you are using the incorrect hard drive name (sda, sdb, etc.) 
Step 5:
Typically, the drive will be marked as frozen (indicated by a line that says "frozen") and will need to be unfrozen before continuing. To unfreeze the drive, put the system to sleep by clicking on the gear icon at the top-right of the screen and selecting "Suspend". After ~10 seconds, hit the power button to wake the system up. It is not uncommon for a system to not resume properly when using a live environment, and if this happens, contact Puget System's Support department to receive guidance tailored for your specific system before proceeding.
Step 6:
Repeat the "hdparm -I /dev/X" command to verify that the drive is now marked as "not frozen". If it is still frozen, you will need to physically disconnect the drive for a few seconds while the system is in the live environment then repeat the command. However, before doing so we recommend contacting Puget System's Support department to receive guidance tailored for your specific system before doing so.

 

Disable the current SED encryption  
Step 1:
After following the steps to locate and unfreeze the drive, run the command "hdparm --security-disable PASSWORD /dev/X" where PASSWORD is the current SED password and X is the drive name (sda, sdb, etc) to remove the current SED encryption. If you wish to leave SED disabled, then the process is complete. If you want to reset SED with a new password, continue to the next section.

 

Enable SED encryption with a new password
Step 1:
After following the steps to locate and unfreeze the drive then to disable SED encryption, next enter the command "hdparm --user-master u --security-set-pass 'PASSWORD' /dev/X" where PASSWORD is the password you want to use and X is the drive name (sda, sdb, etc.) to re-enable SED encryption with a new password.
 
Note: We recommend enclosing the password within single quotes as certain special characters and spaces can cause an error if single quotes are not used.
Step 2:
Enter the command "hdparm -I /dev/X" again and look for the line "enabled" (instead of "not enabled") to ensure that SED is enabled. At this point you should completely power off your system (not a standard reboot) to ensure that the SED password is set properly.

 

Conclusion

After working with SED encryption and seeing how well it works, we are actually very surprised at how little support it has on modern motherboards. In fact, many motherboard manufacturers actively disable SED encryption and require a custom BIOS in order to make it active. Other motherboards, however, do support SED encryption although the ability to manage the password is not available from the BIOS. In those cases, you can still use SED encryption but you need to go though an unwieldy process involving a Linux live environment.

Overall, we have found that SED encryption is great as long as you do your homework and know that it will work on your system. Self-encrypting drives have their downsides (largely that it only requires the password to be entered when the machine is first turned on), but it is easy to use and effective for a very wide range of applications. If you are interested in encrypting your data, we highly recommend checking out SED encryption before considering options like Bitlocker or other software-based encryption.

Do you use hard drive encryption in your computer, either SED encryption or something else? Let us know about your experience in the comments below!

Tags: SED, self-encrypting drive, encryption
openoliv

Hi, very interesting article, but made me sweat big time yesterday...

I've got an Asus UX32VD, with an onboard 32GB SSD, and an HDD.
I replaced the HDD with a Crucial M550 512GB SSD, with SED capabilities.

I wanted to try the SED on the M550 (/dev/sda in the following)
So I followed your tutorial.

1) hdparm -I /dev/sda :
supported
not enabled
not locked
frozen

2) I unfreeze it succesfully with the suspend trick.

3) hdparm --user-master u --security-set-pass yo /dev/sda
(yes, the password is "yo", I'm "yo" person, since a long long time, I should ask money from a recent startup...)

4) hdparm -I /dev/sda :
supported
enabled
not locked
not frozen

5) After restarting the latptop it asks me the password.
User or master password has the same result : FAILED.
I cannot access the BIOS, I cannot start the LiveUSB OS...
My computer is a brick.

6) Don't panic. Well, at least not too much.

7) I take out the SSD. My computer starts again, I can start linux from the USB.
My computer IS NOT anymore a brick.
My newly bought SSD is a brick.

8) I plug the SSD in an external box connectetd by USB.
Whatever hdparm command I use it fails.
Still a SSD brick...
[it seems that the hdparm doesn't work through the USB, is it coming from my computer ? by purpose ? or because of the cheap external box ?]

8) Now I remember that in the BIOS there are some password things... I go there and shazam, I see "HDD password".
I select a "Master HDD password", "qwerty" being my very original choice.

9) I plug back the SSD. It asks me the password. I enter my newly created "qwerty" master password. It works !
I can start Linux:
hdparm -I /dev/sda :
supported
enabled
not locked [ Not sure anymore about this one, maybe "Locked"?]
frozen

Impossible to unfreeze it.

10) Back to the BIOS where I create a "User HDD password" this time. Again, "qwerty" being my very original choice. I enter it when the BIOS asks it later.

11) hdparm -I /dev/sda :
supported
enabled
not locked
not frozen

Wonderful, now I disable it :
hdparm --security-disable yo /dev/sda
[ note that I use my first "yo" password, not the BIOS created "qwerty"]
hdparm -I /dev/sda :
supported
not enabled
not locked
not frozen

12) All good ? not yet :
hdparm -I /dev/sdb :(/dev/sdb is my onboard 32GB SSD)
supported
enabled
locked
frozen

mmhh, something strange here.
I cannot unfreeze it.
Ok, let's reboot. BIOS asks me for the user passord, "qwerty" opens the door.
hdparm -I /dev/sdb :
supported
enabled
locked
not frozen

Second wonderful time, I unlock it, disable it:
hdparm --security-disable qwerty /dev/sdb
[Note that I use the BIOS created "qwerty" password]
hdparm -I /dev/sdb :
supported
not enabled
not locked
not frozen

I've got back a fully functional computer !!!

13) Now, what happened ? I'm far from being able to understand everything here, but here is my guess:
With hdparm I could enable the SED on my Crucial SSD.
When I restarted my computer the BIOS saw a SED enabled disk and asked for the password.
However, instead of applying it on my newly installed SSD it applied it on the "old" onboard SSD, which obviously didn't work.
It seems that the Asus UX32VD BIOS is not ready for SED with both an onboard SSD and a SSD. I'm going to ask Asus about it...
Maybe people with onboard SSD should double check before enabling SED with hdparm !

Posted on 2014-06-30 09:18:37
fsx

Hi Matt,

How do I acquire a custom firmware for self encrypting drive support from ASUS for my MAXIMUS VII GENE with firmware v.2012?

Thank you Matt

Posted on 2014-11-05 12:35:46
cloud atlas

Hello Matt. How strong can the authentication key be? Or does it depend on the specific SED that one uses? I am a person who use to rely on TrueCrypt software encryption before the organization shut down. I'd be interested in a hardware solution where the authentication key can be very strong. For example: 20 or more characters long with upper and lower case and special characters like $ n(< # + .

Posted on 2014-11-27 19:45:39
Fly Guy in SD

Excellent article, this is the first one I've seen that clarifies whether SEDs can be used with Linux at all. It does leave me with a couple of questions, though:

1) In the step on disabling the current SED protection, it says to use --security-disable PASSWORD where PASSWORD = the current SED encryption password. If my understanding is correct, a SED comes with a password generated onboard that is known but to itself; if that is the case, how is one to know what this password is, in order to disable encryption?

2) Having then enabled encryption with a new password, if I were to install Linux on this drive, where would I enter the decryption password at power-up in order to decrypt the drive? The BIOS on my 2011 model Envy 15t-3000 doesn't seem to have any such capacity.

Overall, it's probably academic; the fact that a warm-boot leaves a SED unlocked is a Bad Thing from my point of view. I only power off my machine when I really must, and use software whole-disk encryption; a reboot leaves an attacker to deal with my impossibly long and complex passphrase.

What are your thoughts on using software-based whole-disk encryption with SSDs? There are those who say it's bad...

Posted on 2014-12-09 06:31:23
r0m30

The latest version of msed (manage self encrypting drives) supporting Full Disk Encryption for OPAL compliant drives on bios machines in both Linux and Windows has been released.

Msed is Open source/GPL. The source is available at github.com/r0m30/msed (host management software) and github.com/r0m30/syslinux (pre-boot authentication) with executables at
www.r0m30.com/msed.

Msed uses the TCG OPAL specification for managing SEDs, not the ATA security feature set as highlighted in your article, OPAL specifies a 32 byte AK, msed uses your password and the drive serial number to generate a drive unique 32 byte AK using the PBKDF2<sha1> function (PKCS). Msed does not store you password anywhere, ever, so make sure you take precautions to secure your password.

Sleep (s3) is not currently supported, but hibernation is supported.

Posted on 2015-01-31 23:40:08
mci

Hi, will enabling FDE through BIOS erase my installed system on my hard disk? "hdparm -I /dev/sda" shows "not enabled" at the moment.

Posted on 2016-01-28 12:55:35