How SEDs Really Work

I have been working with hardware and software encryption for well over a decade now and I have seen countless power point presentations on the advantages of hardware encryption over software encryption.  Transparency, performance and security are the big three.

However, I remember the frustration I had when people first described SEDs (Self Encrypting Drives) to me.  I was already familiar with the booting and authentication process for software full disk encryption and I just wanted to understand the same process for SEDs.   Being repeatability “sold” on the benefits (transparency, performance and security) didn’t help me understand how SEDs actually worked.   It wasn’t until someone from Seagate explained the “MBR shadow” to me that I got it.  (Seagate DriveTrust  and TCG Opal SEDs have an MBR (Master Boot Record)  Shadow.)

So here is how the MBR shadow makes SEDs a simple and elegant solution.   The “host” computer (i.e. the laptop) doesn’t get direct access to physical storage media whether it be the media on a spinning hard drive or the solid state memory in a SSD.  Regardless of the media type the drive presents a virtual view of the storage.  In the virtual view the storage space is presented in logical blocks of 512 bytes to the host.   Each logical block gets a number assigned to it, a Logical Block address (LBA).  The LBA starts at zero and goes up to a really big number depending on the size of the drive.  The highest one is called Max LBA.

When the drive ships from the factory it is already encrypting everything written to it.  If you buy a laptop from an OEM  (Lenovo, HP, etc) with say Windows 7 pre-loaded on it the entire drive is encrypted, even Windows.   This encryption is completely transparent to the OS and at this point provides no protection of the data because there is no authentication required to boot.

When our SecureDoc software executes in Windows it first checks if the drive is a SED.  If it isn’t then we encrypt the drive using software but if it is a SED we use TCG commands to create the MBR shadow and write our pre-boot authentication (PBA) software to it.   The MBR shadow is a 128 MB area that is totally “off the map”.  If the OS or a virus were to read each LBA on the drive from LBA 0 to MAX LBA it would still not to be able to see it or modify it.

Once MBR shadow is written by SecureDoc the drive is configured to “lock” in the powered off state.   When the laptop is next turned on it doesn’t see the normal virtual space.  Rather it sees the MBR shadow in the 1st 128 MB of the LBA’s and above 128 MB to MAX LBA it sees only 512 byte blocks of zeros.   That is, the MBR shadow is mapped into the first 128 MB of virtual LBA space instead of the normal Windows MBR.

The host boots into the SecureDoc  PBA code in the MBR shadow  instead of Windows, authenticates the user (e.g. they type in a password), and then unlocks the drive.  At this point SecureDoc maps the MBR shadow out of the LBA virtual space and the normal Windows MBR and the rest of the original drive is mapped in.    The host is rebooted this time into Windows and it boots up as it did before the machine was protected with MBR shadow.

Click the above image to learn more about MBR shadow in our newest whiteboard session.

Previous Post
SESWeb – Private Cloud Ready
Next Post
A new year, same mistakes