A concerning development for Windows 10 has been the discovery that BitLocker can sometimes opt to use unreliable hardware cryptographic capabilities over CPU-based software cryptographic capabilities. This Hardware Based Encryption (HBE) can be enabled when BitLocker is configured for an SSD.
The university research that publicised this weakness was published back in 2018, but it’s now that many corporate environments are starting to move off earlier versions of Windows and turn to Windows 10 in earnest. Moreover, SSDs are now becoming commonplace across a wide range of consumer and enterprise products.
What, you might say, is the problem with HBE? Surely, by using hardware encryption we are offloading all that CPU-cycle hungry encryption and decryption, thereby getting every ounce of performance out of our systems?
It turns out that not all hardware implementations are created equal, or, indeed, capable. Some SSD chips have some alarming defects in their implementations, meaning the performance gain could easily be reversed by the increase in risk from using a flawed cryptosystem implementation.
Some SSDs have an empty master password, and it is that password (or rather, lack of) that protects the keys that are used to encrypt the data [1]. Research by Radbound University shows that a "malicious expert with direct physical access to widely sold storage devices can bypass existing protection mechanisms and access the data without knowing the user-chosen password". Admittedly, this hinges on the device concerned and not all devices may be vulnerable.
However, if devices are used that have weak HBE, this significantly changes the risk dynamic around lost or stolen devices, as data recovery may be relatively easy.
With administrative privileges, it’s easy to check if your current device is using HBE or SBE. From PowerShell prompt with administrative privileges:
PS C:\WINDOWS\system32> manage-bde -status
And look for the "Encryption Method" line. If this states "Hardware Encryption" then HBE is enabled.
The first step is to execute a risk assessment and treatment process, to ensure all risks are captured and managed. This sounds laborious, but these kinds of issues are always best progressed from a thorough risk assessment. Your risk may be relatively low if you are using a verified encryption implementation in an SSD.
The next step is to review Group Policy configuration. Windows 10 Group Policy includes configuration within the BitLocker settings under Administrative Templates that allow the use of HBE to be prevented. This results in BitLocker using software-based encryption, which is clearly preferable. There are lots of other settings within Admin Templates BitLocker, and it pays dividends to research each of these and ensure they are enabled. Settings for secure boot, use of TPM, PINs, and more are by default not configured and should be, particularly in corporate environments.
It is also sensible to use firmware update services from SSD manufacturers, including periodic updates of SSD firmware. On consumer devices, using the manufacturer SSD management tool (for example, Samsung Magician) can provide firmware updates automatically.
More broadly, when creating gold builds for new Windows 10 devices you should always follow best-practice hardening guidelines. There are many of these online, and you can leverage a lot of expertise from them. FDE should always be reviewed as part of a BitLocker deployment.
An alternative approach is to use an encryption product that only supports SBE. VeraCrypt is recommended by some, and some enterprise FDE products also fit the bill. This can be a better approach as you can minimise any potential risk of a change to Group Policy undermining FDE policy.
Encryption always comes at a cost, particularly when we opt for SBE over HBE. Since the advent of newer chipset architectures that have optimised crypto instructions (such as AES), the CPU is able to execute cryptographic operations faster than the latency of SSD I/O. This means the CPU is not the bottleneck when compared to the performance of the SSD. However the CPU crypto cycles will exact an overhead. Microsoft state an overhead of around 5% for BitLocker, though empirical tests have shown overhead of up to 10%. Most applications, particularly EUC, rarely fully utilise the CPU at all times, so the impact is relatively small from using SBE.
Intel processor families that contain the enhanced functionality for BitLocker performance (AES-NI) include Skylake, Goldmont, Haswell, Broadwell, Ivy Bridge, Sandy Bridge and Westmere. Equivalent AMD processor families include Puma, Jaguar and Zen (including Ryzen).
We have analyzed the hardware full-disk encryption of several solid state drives (SSDs) by reverse engineering their firmware. These drives were produced by three manufacturers between 2014 and 2018, and are both internal models using the SATA and NVMe interfaces (in a M.2 or 2.5" traditional form factor) and external models using the USB interface. In theory, the security guarantees offered by hardware encryption are similar to or better than software implementations. In reality, we found that many models using hardware encryption have critical security weaknesses due to specification, design, and implementation issues. For many models, these security weaknesses allow for complete recovery of the data without knowledge of any secret (such as the password). BitLocker, the encryption software built into Microsoft Windows will rely exclusively on hardware full-disk encryption if the SSD advertises support for it. Thus, for these drives, data protected by BitLocker is also compromised. We conclude that, given the state of affairs affecting roughly 60% of the market, currently one should not rely solely on hardware encryption offered by SSDs and users should take additional measures to protect their data.
Radboud University researchers discover security flaws in widely used data storage devices, Radbound University, 2018, link
June 13, 2020