Puget Systems print logo
Read this article at https://www.pugetsystems.com/guides/557
Article Thumbnail

Introduction to Self-Encrypting Drives (SED)

Written on April 30, 2014 by Matt Bach


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.



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

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 :
not enabled
not locked

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 :
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 :
not locked [ Not sure anymore about this one, maybe "Locked"?]

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 :
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 :
not enabled
not locked
not frozen

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

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 :
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 :
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

I have a question about SED and LiveCD attacks. Often my users leave computers running overnight (but locked, e.g. needing a password to enter) for various calculations and what not. I am interested in SEDs to protect against LiveCD attacks. The article says that a SED is not locked when the computer is restarted rather than powered down. Is there anyway that motherboards could be configured such that the SED would require the AK checkout even for reboot and not just power down? That would make it invulnerable to LiveCD attacks. I can't imagine I am the first person to want to do this! I am very new to this world of security, so please pardon my ignorance :)


Posted on 2014-10-27 19:32:32

I don't know of a way to do that with SED. Bitlocker might be able to do it, however, so you might look into that as an alternative.

Posted on 2014-10-27 19:46:02

Huh okay. Is there some standard that says that on reboot power must be maintained? If not, it seems like the motherboard manufacturer could support cutting power to the HD for this exact purpose, but I am sure there is a reason for it being the way it is (you know a hell of a lot more about it than I do!). Sadly Bitlocker is a no go for me as we are an Ubuntu environment.

Posted on 2014-10-27 19:48:46

Yea, that might be possible, but I bet you would find it pretty much impossible to get a motherboard manufacture to create something that custom for you. Especially since power to the drive is usually provided independent of the motherboard. I wonder if an easier solution may be to somehow disable restart in Ubuntu so that your only choice is to power down. I don't know how that would be done, but it would probably be easier to figure out than getting a custom motherboard that cuts power to the drives ever reboot.

Posted on 2014-10-27 20:03:08

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

You'll have to contact Asus support to request a custom BIOS with SED enabled.

Posted on 2014-11-05 19:12:40

Hi Matt,

Thank you for responding...do you have a specific contact within ASUS? I've already tried to ask ASUS Support via their support page help form and they mistakenly assumed I was asking for "Secure Erase" compatibility for my motherboard...they were unhelpful and I waited 3 days just for that response...

I would like to hopefully find an ASUS Support Rep that is able to do this for me.

Posted on 2014-11-05 19:46:43

Unfortunately, all of our contacts are engineers/sales for business. You might try posting on Asus' forum, at least that way you might be able to get them to at least understand what you are looking for.

Posted on 2014-11-05 19:55:35

Oh, ok thank you.

Posted on 2014-11-05 20:05:05

Hi Matt. Thanks for this very informative article on SED drives. One question, though. I plan on buying a SED compatible laptop with no OS installed. Is there a preferred order - enable SED encryption (using LiveCD), then install the OS or install the OS on SED then enable SED encryption - or does it not really matter which order it is done. Thanks again.

Posted on 2014-11-25 15:51:24

I don't think it should matter, but personally I would enable SED first then install the OS. Just in case you run into a problem with enabling SED or accidentally do a secure erase or something like that.

Posted on 2014-11-25 18:45:37
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

I'm pretty sure the authentication key accepts upper/lower case and special characters, but I can't find anything definitive on the maximum length. It sounds like it may vary by manufacturer, so it will likely depend on the motherboard brand.

Posted on 2014-12-01 18:40:30
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

1) I think you are mixing up the Data Encryption Key (DEK) and the Authentication Key (AK). The DEK is what all SED drives come with and is the actual encryption key for the drive to be able to decrypt the data stored on the drive. The AK is what you can set and basically tells the drive to not provide the DEK until the correct password has been entered. So if you don't provide the correct AK, the data on the drive will continue to be encrypted.

2) The nice thing about SED is that it is completely OS independent. Everything is done at the BIOS level, so you could have any OS on the drive or it could simply be a storage drive and it will work the same. The problem with this is exactly what you see with your laptop: the BIOS must support it or you won't be able to set an AK (password).

Personally, I feel that the choice between hardware (SED) and software (Bitlocker, etc) encryption comes down to the use-case. Hardware level encryption should be more secure as long as you power off the machine when it isn't in use, but if the machine is left on (even in standby) and an attacker knows that you are using SED they can potentially access the data on the drive by reconnecting the data cable to another machine without cutting power. On the other hand, I believe that software encryption is much easier to crack (still really difficult, but easier than SED) so the data is more vulnerable if the drive has been powered down.

I'm no expert on drive encryption (SED is the only one I really know a good deal about), so take my opinion worth a grain of salt. I like SED more since it is completely OS independent, but I also tend to lean toward hardware-level solutions over software-level ones.

Posted on 2014-12-09 19:47:46

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

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

I am trying to figure out what happens after a bunch of incorrect passwords? Does the drive automatically wipe? What prevents someone from just setting up a program to try password combinations until they get in?

Posted on 2015-12-01 23:07:59
Anonymous Frank

Sure they can do that, but it would take a long time. Let's say they were somehow able to guess a million passwords a second, which is likely WAY more than a SED drive could possibly test at a time (most likely it would be under a thousand a second). Even at a million per second, an 8 character password would still take more than 200 years to wipe. A 10 character password would take a little under 200 aeons to wipe! So yeah, good luck with that.

Posted on 2016-02-25 12:02:48

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

we'll why don't the manufacturers release the exact details of their encryption in a user verifiable way?

i mean if they are sure it's good and has no backdoors.....

btw, don't use bitlocker, ms stores copies of your keys

Posted on 2016-06-08 16:01:24

Hello Matt,

Thank you for the good article!
I try to understand the difference between hdparm and sedutils ? Is it that both do the same and are alternative to each other ?
Or is it the hdparm can only lock/unlock but requires BIOS support (while sedutil manage the unlocking in boot too) ? If this is the case it means that if hdparm is used for sed we MUST have bios support for SED.

Thank you!

Posted on 2018-11-13 19:45:32