How to Enable Bitlocker Hardware Encryption on SEDs

• Download source code - 858 B

Introduction

This article is a guide on how to activate Bitlocker hardware encryption (aka IEEE1667 or Microsoft eDrive) on SEDs (self encrypting drives) in Windows. I have been using SEDs since May 2016 (my first drive was a Crucial MX200) and at that time, there wasn't too much documentation about how to activate flawlessly hardware encryption in Windows. I wanted to publish this guide then, but I was "too lazy". I only posted some hints on forums till now when I decided to write this article.

Background

SEDs aka Self Encrypting Drives are particular type of hard disks which have onboard a crypto processor which encrypts on the fly every block of data written from the computer to the drive controller and, vice versa, decrypts every block of data read from the drive for the computer, in a transparent way to the users, except for an initial provisioning phase. In essence, each SED has a disk encryption key (DEK) that is set at the factory and stored safely inside the crypto processor. The disk uses the DEK to encrypt everything it writes and to decrypt everything it reads.

SEDs then also use an authentication encryption key (AEK) provided during the boot of operating system either by the user (for Windows through either a password or PIN) or by the Trusted Processor Module (aka TPM) to protect its DEK. SEDs have a mode referred to as auto-lock mode, e.g., when a disk is powered off, they get automatically locked; when later the disk is powered on again, the SED requires a valid AEK in order to read (and decrypt) the DEK needed to unlock the disk and perform any read and write operation. If the SED does not receive a valid authentication key, the data on the disk cannot be read. The auto-lock mode also helps to protect the data when disks are accidentally or intentionally removed from the system (disconnected lively from a SATA cable of a computer in order to get connected to another SATA cable in a different computer).

How to Enable Bitlocker Hardware Encryption

Precondition: The SED must explicitly have in their technical specification the support to IEEE1667 or Microsoft eDrive, otherwise, it won't work. TCG Opal is another security storage specification and it is not enough for Bitlocker hardware encryption. There are drives which do support both standards (TCG Opal and Microsoft eDrive), for example, Crucials and Samsungs usually do.

It's a nine step process, which must be followed even with a brand new drive.

1. Update computer BIOS and SED firmware to the latest version. Sometimes, in order to update them, you need to disable Bitlocker encryption (if you use TPM), so it's better to do it as first point. In BIOS:
   • Disable UEFI CSM (Compatibility Support Module) option, if present
   • Ensure that Secure Boot option is set to Custom for the entire setup, this allows Bitlocker to enroll boot keys for booting without a password the SED. Moreover, it allows you to enroll boot keys for multi image booting tools like Ventoy.
   • Reset Secure Boot keys to platform default (optional step to restore TPM keys to factory default)
2. Check on SED hardware vendor website if and how IEEE1667 or Microsoft eDrive should be first activated (optional step depending on hardware vendor): This is usually performed through their management software (Samsung Magician for Samsungs, Kingston SSD Manager for Kingston SEDs, etc., Crucials have it instead activated by default).
3. Prepare a bootable usb drive (I would say 64GB or bigger) for the next operations: personally, I use the Ventoy usb tool which came out in 2020 and it has quickly become a must have for any IT Administrator or enthusiast since it allows you to configure multiple booting images on a single USB drive in a very simple way. First and foremost, you install it on an USB disk and then you can copy any iso image in any format (ISO/WIM/IMG/VHD(x)/EFI) you want; when you restart your computer and boot it, it will scan all the iso images inside and let you pick through a menu which one you would like to boot (in my usb key, I put the latest Windows to be installed, the Samsung SecureErase, the MemTest86 and an Ubuntu live image for emergency).

   If your bios does not have the Disable Block SID option, you need also to build a WinPE image (e.g., a live Windows iso which runs in RAM without being installed) with Powershell core or Powershell in order to configure such option through a script; incredibly, I wasn't able to find any iso image like this publicly available. To build the iso image, you can use a tool like Win10XPE (the link is to the project website for the documentation, but incredibly it does not contain the binary, I downloaded it from Sourceforge). It is simple to use (it has a GUI), essentially you have to:

   • Download the latest Windows (10 or 11) ISO image from the Microsoft website
   • Select it in the main window of Win10XPE
   • Configure any feature you would like to have in the iso image by selecting checkboxes, in our case, we need Powershell Core, but you can add as many as you like (the more tools you add, the bigger the image gets, but with around 3GB, I was able to fit almost any needed tool). There is even the possibility to configure hardware vendor management software like Samsung Magician!

     

     After configuration, you have to hit the play button and wait for the iso image to be built (takes less than 10 minutes), then you can copy it to the Ventoy usb drive, together with the 2 Powershell scripts (DisableBlockSid.ps1 and DisableBlockSid_Core.ps1) provided in the archive attached to this article (Download DisableBlockSid.zip).

     

4. PSID revert the SED: All SEDs have a 32 hexadecimal characters code physically printed on their label with the heading PSID (aka Physical Secure ID, check picture below). This code can be passed to a tool in order to bring the SED back to factory state destroying also any data on drive since this operation also creates a new DEK which makes all user data on drive unreadable.
   Again, I repeat it, you must do this, even for brand new drives, otherwise it won't work. I have always used sedutil-cli which is the first official executable tool provided by Drive Trust Alliance, available for both Linux and Windows. You can read the documentation and download the binaries. Remember that the PSID must be quoted in upper case letters without any dashes. Nowadays, this PSID revert function is even integrated in UEFI bios or in the SEDs hardware vendor management software, pick the one which works best for you.

   

   Check that this operation nukes the SED (e.g., deletes all partitions and all data on disk), you can test this by creating before a partition and a simple text file with whatever characters you like inside, after this operation there won't be any partition and obviously any file. If this is not the case, then the drive is not fully compliant to the TCG standard (PSID revert should be the standard command to be executed); if not fully supported, you need to use what the hardware vendor management software reports (for my Samsung 990 PRO SED I had to use Samsung SecureErase as stated in Samsung Magician which unbelievably did not even ask for PSID to nuke the drive, I will follow up again with Samsung since from the security viewpoint this behaviour is very dangerous as an attacker could nuke all your data by issuing such command without any human confirmation).

   Note: I followed up with Samsung about this previous SecureErase point and I discovered the main difference between PSID Revert and SecureErase (for Samsung):

   • The SecureErase procedure does not ask correctly for the PSID since you are only allowed to SecureErase a Samsung SED only if the disk is not encrypted yet.

   • If you want SecureErase again an encrypted disk you have to first PSID Revert it by providing the PSID.

   

   Since I always test by myself critical points like this, I made a "kamizake" attempt to try again to SecureErase my newly re-installed SED and this time, I received correctly an error as you can see in the picture below; moreover I was quite happy that I did not have to reinstall everything from scratch for the sixth time. :-)

   

   Summing up for Samsung SEDs, the PSID Revert and SecureErase are two separate functions whereas in Crucials, there is no SecureErase procedure, the PSID Revert performs both functionalities in a single command. If you manage to find any other hardware vendors with another variation of this step, please let me know.

5. Disable the Disable Block SID option either through BIOS (if supported) or through the Win10XPE iso image you have built in step 3 by running one of the two attached scripts. Essentially, both the two provided scripts contains a single command line, SetPhysicalPresenceRequest (97) on the TPM instance, e.g.:

   Powershell (DisableBlockSid.ps1)
   powershell.exe -ExecutionPolicy bypass -Command "(Get-WmiObject -Namespace "root\CIMV2\Security\MicrosoftTpm" -Class Win32_TPM).SetPhysicalPresenceRequest(97)"

   Powershell Core (DisableBlockSid_Core.ps1)
   pwsh.exe -ExecutionPolicy Bypass -Command "Get-CimInstance -Namespace 'root/cimv2/Security/MicrosoftTpm' -ClassName 'Win32_TPM' | Invoke-CimMethod -MethodName 'SetPhysicalPresenceRequest' -Arguments @{Request='97'}"

   If you would like to know why 97, you can check out the document about Physical Presence specification on TCG website (at the bottom of page 60). At the next reboot, you should be seeing a warning message at boot like the one below which you must accept (hit F10). Note that this is valid only for the next boot so you have to boot the official Windows iso image to start the installation, if not, you have to redo this when you are ready to install it.

   

6. Perform a fresh install of Windows (Windows 8 upwards).
7. Enable hardware-based encryption in Bitlocker's Group Policy for both fixed and operating system drives: launch gpedit.msc and set
   • Computer Configuration -> Administrative templates -> Windows Components -> Bitlocker Drive Encryption -> Operating System Drives -> Configure use of hardware-based encryption --> Enabled
   • Computer Configuration -> Administrative templates -> Windows Components -> Bitlocker Drive Encryption -> Fixed Data Drives -> Configure use of hardware-based encryption --> Enabled

     Check also that option "Use Bitlocker software-based encryption when hardware encryption is not available" is unchecked in order to avoid fallback to software encryption when things do not work.

     

8. Try to turn on Bitlocker on drive (e.g., right click on disk drive -> Turn Bitlocker On). There are two outcomes:
   • There is something which prevents the activation of Bitlocker hardware encryption. In this case, you have to try again the procedure from scratch (yes from scratch), but you can check the Windows Event Viewer for some hints about what went wrong under the nodes Application and Service Logs --> Microsoft --> Windows --> BitLocker-API --> Management and Application and Service Logs --> Microsoft --> Windows --> EnhancedStorage-ClassDrive --> Microsoft-Windows-EnhancedStorage-EhStorClass/Operational, even though most of the events logged there are murky for those who do not know the details of the provisioning process of a SEDs including me (you can send them however to the technical support of your vendor).

     

     

   • If everything is fine instead, you will be prompted to reboot your machine. At the next reboot, the hardware encryption will be enabled automatically, you can check that by issuing manage-bde -status in an administrative prompt or powershell and you should be seeing in Encryption Method "Hardware Encryption - <OID [object identifier] for the crypto algorithm used>", in this case 1.3.111.2.1619.0.2 is XTS-AES-256.

     

     If after the reboot, you see the window below, it means that you didn't put Secure Boot option in Custom mode in order to seal encryption keys into TPM. Do not worry, just reboot, change the bios settings and retry to turn on again the Bitlocker encryption in Windows.

     

9. Perform a last reboot and switch back in bios the Secure Boot option from Custom to Enabled (or Standard) in order to forbid any key management operation.

Points of Interest

I have tested the above procedure on 6 Crucial drives and it has always been successful, so it should be quite trustworthy. Moreover, I have recently bought a Samsung 990 PRO NVME SED (the top product in Samsung NVME drives) and I was unable to activate hardware encryption on it with this procedure due to a bug in the firmware (I submitted a ticket to Samsung, they acknowledged the issue and released a new firmware which I still have to test due to lack of time, even though others have reported it as working). So this should be a further bonus point for the above procedure.

Note: Six months after the new firmware was released for Samsung 990 PRO, I tried again to configure Bitlocker hardware encryption and at the beginning I was not successful since I was not performing a SecureErase with the Samsung provided tool and not activating the Disable Block SID option since it was not present in the BIOS of my actual laptop (on my older laptop for some reasons now unknown to me, it was not needed or maybe it was already disabled). After a thorough research, I managed to find a way to disable it by script and to activate successfully hardware encryption also on my Samsung 990 PRO as you can see in the screen below:

With the benefit of the hindsight, I would say that I submitted a bug to Samsung "wrongly" (even though I sent them also the procedure I was using, see email below) because I was not following the right procedure with their SSD (as you learnt from this article, for them it is a little bit different) even though before submitting the bug, I read almost all internet forums on the subject and there was no one able to activate Bitlocker hardware encryption on a 990 PRO. Samsung for some reasons again unknown to me acknowledged an issue and released anyway a new firmware which now I can confirm to be working. It would be interesting to try the right procedure also on the older firmware to see that it was not working, but I have no time so I trust what other users reported in forums, e.g. it was not working.

As other point of interest, I remind that since 2008, the Intel (and AMD) processors do support the AES-NI instruction set which performs AES encryption quickly in hardware, so disk encryption has been historically performed on the computer by using the CPU. So one could be wondering what is the advantage in using the SEDs and the answer is a single word: DMA.

At the beginning, computers were using Programmed Input Output (aka PIO mode) to access peripherals like hard disks which required that the CPU was the one actually performing the transfer of data for any read / write operation by using memory mapped registers, thus making it unable to perform any other work during IO operations. Then Direct Memory Access (aka DMA) was developed in which the CPU offloaded the management of I/O operations to another processor, the DMA controller, freeing the load on CPU and allowing it to perform other work. When using the CPU based encryption (AES-NI instruction set or similar) the DMA benefits get greatly reduced since the processor has to intervene accessing the memory in order to decrypt the data after a read operation as well as to encrypt the data before a write operation (so the offload of I/O is partial and therefore, you should be experiencing higher CPU utilization during I/O). When using SEDs, this drawback does not happen and this is a bonus point for them, at least for now. And who knows, perhaps one day, the DMA controller will integrate a crypto processor inside allowing encrypted transfers not only from/to SSD but also from/to any peripheral on the bus.

Another bonus point for SEDs is the encryption speed which is faster on them even though both SEDs and x64 CPU perform AES encryption in hardware. X64 encryption speed is lower due to the general purpose of the chip and due to the fact that it has also to run the operating system besides other processes while it is encrypting. I have an Intel Core i9 I13900H processor (so a quite recent and I would say performing CPU) and using Veracrypt benchmarking function, I got these results:

As you can see, X64 hardware encryption is around 6.5 GB/s which is a lot, but not enough for keeping the pace of PCIe 5.0 NVMe SSDs which top up to 12 GB/s and theoretically up to 14 GB/s. Using CrystaDiskMark on the hardware encrypted Samsung 990 PRO (which I remind is a PCIe® 4.0 SED) I top up 7.1 GB/s in read and 6.8 GB/s in write which is higher than Intel AES-NI, but it does not come very close to the 8GB/s theoretical bandwidth probably due to a non top performant NAND flash. I am eager to see PCIe 5.0 SED benchmarks as soon as they come out.

4 GB data benchmark

1 GB data benchmark

Another point of interest is the SecureErase function implicitly available in every SEDs: if needed, for whatever reason, you can nuke all its data in an instant being quite confident that it won't be recovered almost in any way.

Last but not the least, I mentioned the TPM, to give a primer about it, I can just say that it is an additional crypto coprocessor in the motherboard (or even software emulated in the processor security enclaves like in Intel chips through PTT feature) which stores securely any encryption keys (AEK for SEDs) through the sealing technique. Basically, the TPM encrypts any key with its own factory installed hardware key and saves some key metrics about the hardware/software configuration of the system (CPU, motherboard, etc.).; the TPM during the boot process, after having validated that the hardware/software configuration has not changed "provides automatically" the encryption keys (AEK for SEDs) for decrypting and booting the drive without any input of the user. So as long as you do not change your hardware/software configuration, you won't be prompted for any password or pin during boot. In case instead, you need to change the hardware configuration (e.g., upgrade CPU, update BIOS, etc.), you had better disable the drive encryption, otherwise you would need to provide the Bitlocker Recovery Key in order to access the drive after such change.

SED Security

There is a paramount question that I think most of the users who are going to buy a SEDs wonder: are they really safe ? Well, SEDs security is coded and managed mainly by their firmware and to be secure a sound implementation is required, which for the first devices (including the Crucial MX200 which I still have) was not. You can check this paper (also here) for details, it was published in 2019 and analyzed SEDs produced between 2014 and 2018 (so not the most recent ones), hopefully hardware vendors should have addressed their implementation flaws with firmware updates or newer products, but unluckily, I haven't found a recent paper on the state-of-art of SED security. Let's hope it is, even though I shall remind everyone that a flawless implementation in a software has never been seen, at least till now.

History

• V1.0 (9^th November, 2023)
  • Initial version
• V1.1 (11^th November, 2023)
  • Added insight on encryption speed and SED security section
• V1.2 (3^rd December, 2023)
  • Added "prepare a bootable usb drive" and "Disable Block SID option" steps.
  • Improved "PSID revert the SED" step
  • Added note on Samsung 990 Pro in Points of Interest
  • Added further screenshots and scripts
  • Added benchmarks in Points of Interest
  • Added bonus point of SecureErase functionality in Points of Interest
• V1.3 (7^th December, 2023)
  • Added note on difference between PSID Revert and SecureErase (for Samsung drives) on PSID Revert step