How Self-Encrypting Drives (SEDs) Work

SED means that instead of relying on the host processor and software for full-disk encryption (FDE), the encryption is done purely by the drive itself using Trusted Computing Group's (TCG) Opal standard. The Opal standard offers two major benefits over software based disk encryption: performance and security.

Instead of using the host resources (CPU and RAM) to encrypt the drive, the controller inside the SSD does the encryption, which provides higher performance due to the lack of CPU overhead and is also far more power efficient. In fact, the controller already encrypts all data on the fly regardless of whether encryption has been enabled by the user -- by default the encryption key in the drive is just not encrypted and thus the drive can be accessed by anyone. When enabling Opal encryption the password created by the user is used to encrypt the encryption key, making the drive inaccessible unless the correct password is provided. The encryption key is generated during the manufacturing process of the drive (although it can be regenerated later on) and resides in a small secured block of memory that is protected and isolated from other memory.

As for security, software encryption solutions do not generally encrypt the master boot record (MBR), which leaves the drive vulnerable to attacks using alternative boot medias (CD/USB). Hardware encryption does not have the same problem because every single bit that the drive receives will be encrypted, including the MBR. Basically, hardware encryption is transparent to the OS because the drive does not know or care what data it receives as all data is encrypted regardless.

Because even the MBR is encrypted, SEDs have a pre-boot OS that is essentially a very restricted version of MS-DOS or Linux. When the BIOS requests the MBR from the drive during boot, the drive instead returns the pre-boot OS that asks for authentication before allowing access to the MBR. Once the correct credentials have been provided, the drive allows the BIOS to access the MBR and the system will boot normally.

Testing Wave's EMBASSY Security Center

Every X300s includes a license for Wave's EMBASSY Security Center (ECS), which normally retails for $40. ECS can be acquired from SanDisk's SSD Dashboard under the Tools tab. ECS provides local SED management, and for IT administrators Wave offers EMBASSY Remote Administrator Server (ERAS) that allows central management of all SEDs in the organization.

Clicking the icon will lead you to the download site where you enter the promo code that comes with the SSD Dashboard as well as your personal details (name, address, email etc. -- no credit card is needed). Once you have entered all the information, you will be able to download the ECS and the serial key is sent to the email address you provide.

After installation and reboot, you will be ready to enable encryption. Drive management is found under the 'Trusted Drive' tab and at first everything is in the off state and the only option is to start the initialization process. For testing I used a very basic Z87 based system running Windows 7 in legacy mode with no TPM module.

The first step is to create the administrator for the drive, which will have the right to manage the drive. After the initialization process additional users can be added but I will look at that once we are there.

After creating the administrator, you will be given an opportunity to either print or save the administrator username and password to a USB drive. This step can be skipped but it is recommended since if the credententials are forgotten, you will be unable to access the drive and the only way to recover the drive is to perform a PSID reset (more on this later but it erases all the data in the drive).

After that you are done -- the drive is now fully encrypted. It only takes a few seconds to encrypt the drive because as I mentioned earlier, all the data in the drive is already in encrypted format and thus only the encryption key needs to be encrypted. You can check that the drive is really encrypted from the SSD Dashboard, which should now say that security is activated.

This is what the drive management looks like. The administrator has the right to un-initialize the drive, which will decrypt the key and make it accessible by anyone. There is also an option to disable drive locking, which is different in the sense that the drive will allow anyone to access the data but only the administrator can change the encryption settings (e.g. un-initialize or crypto-erase the drive). Additionally Wave can sync the drive's and Windows' passwords so there will be only one password, or you can enable single sign on that will eliminate the need to log into Windows separately.

Users can be added within the same interface to allow non-admin users to get through the pre-boot OS. Otherwise every user would need to use the administrator credentials, which would defeat the purpose of an administrator account as it is the only account with rights to manage the drive. In other words, normal users can use the system normally but administrator rights are needed to un-initialize the drive or change any settings related to security.

ECS also offers several options for Windows login. Aside from the typical password authentication, the user can login using biometric authentication (e.g. fingerprint), and smart cards are supported as well. Again, these settings can only be modified by the administrator, even though they are visible to the normal user.

SanDisk X300s 512GB - PCMark 8 Storage Test
  Storage Score Storage Bandwidth
No Encryption 4976 268.1MB/s
Wave ECS (Opal 2.0) 4974 265.1MB/s
Windows 7 BitLocker (Software) 4960 246.6MB/s

To compare the performance of hardware and software based encryption solutions, I decided to run PCMark 8's storage test on the drive with the two enabled (separately, of course) and with no encryption at all. Strangely enough, the performance difference is almost non-existent. When Anand tested eDrive with the Crucial M500 and PCMark 7, he found that software based BitLocker encryption resulted in a 14% decrease in performance, whereas my test data shows a mere 0.3% loss in Storage Score. It is true that the PCMark 8's storage bench is different and in my experience it tends to show very small difference between SSDs but nonetheless it is still interesting that BitLocker has such a minor impact in performance.

Of course, my testbed is not exactly an ideal representation of an average corporate laptop since it is a Haswell based desktop with i7-4770K and 16GB of RAM, so the difference in lower performance systems might be larger as BitLocker will use the host CPU and RAM for encryption. Anyway, it looks like I will have to run some more tests to figure out a way to better characterize the performance benefits of hardware accelerated encryption because I believe the scores above do not give an accurate picture of the difference.

Crypto-Erasing an SED

Since SEDs are hardware encrypted, there is no way to fiddle with the drive without the administrator's credentials. However, what that also means is that in case you happen to forget the credentials, you will have a brick in your hands since SEDs cannot be secure erased using the standard ATA command like normal SSDs can. Fortunately, there is a way to revert the drive back to its factory setting by performing crypto-erase, or PSID revert as it is sometimes called.

The PSID can be found on the back label of every SED and it is a 32-character code.

To issue a crypto erase, a special utility is needed and SanDisk provides their Crypto Erase Tool for the X300s. It is very simple to use as the only thing you need to do is to enter the PSID and click erase now, which will deactivate encryption and secure erase all the data in the drive. I am not sure if SanDisk's tool supports other SSDs but in theory it should as there is nothing vendor-specific about crypto erase. However, there is also a third party freeware PSID revert tool available and I have confirmed that it works (tested with Samsung 850 Pro).

Final Words About Wave's ECS

Wave's ECS certainly provides a much smoother user experience compared to Microsoft's eDrive. It makes enabling Opal 2.0 encryption as easy as clicking a few buttons and it lacks the annoying hardware and software requirements that eDrive has. There is no need to play around with group policies if you lack a TPM module and what is best is that ECS is not limited to a UEFI-enabled Windows 8 Pro/Enterprise install like eDrive is. Basically, ECS should work with any system as long as you have an Opal-enabled SSD.

eDrive is a good (and free) alternative if you happen to have a system that meets the requirements, but otherwise it is a pain to get working, so I certainly see why corporations will gladly pay for ECS and other optimized encryption tools.

Introduction, The Drive & The Test Performance Consistency
Comments Locked


View All Comments

  • vaayu64 - Thursday, August 21, 2014 - link

    Thanks for the review, as always =).
    If you have the opportunity to meet with sandisk, can you please ask if there will be a msata version of their extreme or ultra ssd.
  • vaayu64 - Thursday, August 21, 2014 - link

    Another question, does this X300 provide power loss protection?
  • hojnikb - Thursday, August 21, 2014 - link

    Looking at the PCB it appears not.
  • Samus - Thursday, August 21, 2014 - link

    That's too bad since it clearly has a piece of (undisclosed capacity) memory on the PCB. Looks to be a 128MB DDR2 chip. I wonder if any user data is stored in there of if it truly caches only the indirection table?
  • Kristian Vättö - Thursday, August 21, 2014 - link

    The X300s does not have capacitors to provide power-loss protection as that is generally an enterprise-only feature. SanDisk does have a good white paper about their power-loss protection techniques, though.
  • Samus - Friday, August 22, 2014 - link

    Enterprise-only feature? Many mainstream drives have capacitors dating back to the Intel SSD 320 (X25-M v3)

    Some of the cheapest SSD's on the market have capacitors (Crucial MX100) so its inconceivable to leave them out in 2014.
  • Kristian Vättö - Friday, August 22, 2014 - link

    "Many mainstream drives have capacitors dating back to the Intel SSD 320 (X25-M v3)"

    There is only a handful of client-grade drives that provide power loss protection in the form of capacitors (Crucial M500, M550 & MX100, Intel SSD 730 & SSD 320 are the only ones I can remember).

    The SSD 320 was never strictly a client drive as Intel also targeted it towards the entry-level enterprise market, hence the power loss protection. The SSD 730, on the other hand, is derived from the DC S3500/S3700, so it is basically a client tuned enterprise drive.

    The power loss protection in the MX100 and other Crucial's client drives is not as perfect as their marketing makes you think. Crucial only guarantees that the capacitors provide enough power to save the NAND mapping table, which means user data is vulnerable to data loss. That is why the M500DC uses different capacitors because the ones in the client drives do not provide enough power to save all writes in progress.

    SanDisk's approach is to use nCache (i.e. an SLC portion) to flush the NAND mapping table from the DRAM more often. The lower write latency that SLC has ensures that in case of a power loss, the data loss is minimal but it is true that some data may be lost. Crucial/Micron operates all NAND as MLC, which is why they need the capacitors to make sure that the NAND mapping table is safe.
  • hojnikb - Friday, August 22, 2014 - link

    On the subject of mapping tables; how does controllers like sandforce (and some marvell implementations) work without DRAM ? Do they dedicate a portion of flash for that and how do they keep track of that portions activity (eg block wear) ?

    Also, since some of the manufactures use pseudo SLC (ie MLC/TLC acting as SLC) how is endurance of those cells affected ? Can SLC portion last longer than normal MLC/TLC ?
  • Kristian Vättö - Friday, August 22, 2014 - link

    The controller designs that don't utilize DRAM use the internal SRAM cache in the controller to cache the NAND mapping table. It just requires a different mapping table design since SRAM caches are much smaller than DRAM. Ultimately the mapping table is still stored in NAND, though.

    Pseudo-SLC can definitely last longer than MLC/TLC. With only one bit per cell, there is much more voltage headroom as there are only two voltage states.
  • hojnikb - Friday, August 22, 2014 - link

    So really, MLC/TLC and SLC dies do not differ much internally. I'm guessing that real SLC just uses less on die error correction than MLC, but cells shouldn't be that different at all. Same i suppose goes for TLC aswell.

    If this is the case, it brings an interesting question; If one were to buy MLC drive and wanted SLC grade endurace, it could (if access to firmware was available) tweak the firmware in a manner, so the whole drive would act as a pSLC; obviously at a cost of performance. Something like nCache 2.0, but expanded to whole capacity.

    I believe some cheap flash drive controllers offered something like that using their MPtools. I remember messing around with a cheap TLC based flash drive; Once done, i ended up with 1/3 of the capacity, but write speeds increased dramaticly.

Log in

Don't have an account? Sign up now