Self-Encrypting Drives (Part II)

In our first blog, i.e.Why Self-Encrypting Drives (SED’s)? Part I, we talked about the problems faced by businesses in terms of data security and a brief introduction about the Self-Encrypting Drives.

In this part, we would be discussing about the working of SED’s, benefits of using SED in the current scenario and the challenges associated with it.

As per the survey conducted by CIO Insight in 2015, when asked about what type of data needs to be protected the most? 89% respondents chose Financial documents, 52% said Trade secrets and Intellectual property, 41% said Employee Records and 39% selected Customer data.

Having said that, we know how important it is to protect data today in this era of frequent data breaches, data loss and substantial increase in the rate of cybercrime. The next important question that needs to be addressed is: How to protect this vital data?

SED pioneer Robert Thibadeau says “A strategy to migrate to SEDs is a good one for the improvement in assurance that IT can have, that the data at rest problem is now well-handled”.

How does an SED work?

  • The encryption key used in SEDs is called the Media Encryption Key (MEK). Locking and unlocking a drive requires another key, called the Key Encryption Key (KEK) supplied by the user (or the platform, or the network).
  • As the name implies, the KEK is used to encrypt or decrypt the MEK. The KEK is never stored in plaintext inside the drive. If no KEK is set, the drive is always unlocked and appears not to be encrypting even though it is. If a KEK is set, the drive will power up locked until the correct KEK is given to the drive by the user.
  • When a locked SED is powered up, the BIOS first sees a shadow disk that is much smaller than the real disk. The shadow disk is usually around 100 MB. The software in the shadow disk is read-only, and this software requires the KEK from the user to unlock the real disk for use and to decrypt the MEK so the real disk can be read and written to.


  • The shadow disk software stores a cryptographic hash of the KEK so it can recognise if the user gives the right KEK. When the user enters the passcode (KEK) the shadow disk creates a hash of that passcode and compares it with the stored hash of the KEK.
  • If the two match, the MEK is decrypted and put into the encryption/decryption circuit inside the drive, the BIOS is called to start from the disk again, but now this is the much bigger real disk with a capacity in gigabytes rather than megabytes, and the operating system boots normally.
  • This shows one of the chief benefits of SEDs. By design, SEDs do all the cryptography within the disk drive controller, which means the disk encryption keys are never present in the computer’s processor or memory, where they could be accessed by hackers.

Likewise, authentication of the user is done within the SED and never exposed within the memory or operating system of the computer, which means attacks on vulnerabilities in the operating system cannot be used against an SED’s pre-boot process.

Challenges for SED’s:

The below identified issues surround the usage of SED drives with the Opal standard in enterprise environments:

  1. The Hot Plug Attack where they install a SATA data and power extension cable while the machine is in Sleep mode.
  2. The Forced Restart Attack where they trigger a soft-reset and boot from an alternative OS on a USB memory stick.
  3. The Hot Unplug Attack where they attack exposed SATA data and power pins.
  4. The Key Capture Attack where in Sleep Mode (S3) they replace the SED with a tampered drive with custom firmware or sniff the SATA bus to get the password.

We would be discussing in detail about the solution that would address all the issues/challenges for SED’s in our next article. Stay tuned!

Leave a Reply

Your email address will not be published. Required fields are marked *

sixteen − thirteen =