Suspected Security Breach?

Hardware Encryption Weaknesses and BitLocker

Hardware encryption implemented within certain Solid State Drives (SSDs) can be exploited to recover all encrypted data without needing to know any secrets.

By Robert Nicholls

Managing Consultant, Assurance

08 Nov 2018

These weaknesses were discovered by researchers from the Radboud University and the Open University of Netherlands in early 2018, and were recently published in a draft paper. One mitigation is to enable the use of software encryption such as Microsoft’s BitLocker using specific configuration settings.

Full Disk Encryption Methods

An increasingly common method of implementing full disk encryption involves the native hardware encryption capability of a self-encrypting drive (SED). Drive manufactures typically meet the Trusted Computing Group’s (TCG) Opal core specification for their SEDs, which mandates the use of either 128-bit or 256-bit encryption using Advanced Encryption Standard (AES). Some of the advantages of using hardware encryption include:

Encryption is invisible so it can be used with any operation system

Encryption key cannot be accessed by the host

There is no performance overhead

Data can be wiped by erasing the data encryption key

An alternative to hardware encryption is the use of software encryption. This allows traditional hard drives and SSDs that don’t support hardware encryption to provide full disk encryption. Some of the disadvantages of software encryption include:

Encryption software has to be supported by the operating system

Encryption key is cached in the host's memory

There is a performance overhead

However, there are some advantages to using software encryption as some software, such as Microsoft’s BitLocker, can support multifactor authentication using a device’s unique Trusted Platform Module (TPM). Depending on the TPM implementation, this can offer tamper-resistance and protection from certain software bugs.

Hardware Encryption Vulnerabilities

The draft research paper identified that some common SSDs have critical security weaknesses that can allow the recovery of all encrypted data without needing to know any secrets. The following drives were reviewed and found to contain weaknesses:

Methods of exploitation involved modifying the disk’s firmware, typically using a Joint Test Action Group (JTAG) debugging device. This allowed password verification routines to be tricked into unlocking the drive using its data encryption key (DEK). This could occur on some devices because there was no cryptographic binding between the password and the DEK.

Manufacturer Responses

Micron have developed firmware patches for their Crucial drives, with MX100 and MX200 firmware updates available now. The firmware update for the MX300 will be added on November 13th. The Crucial Team have stated that MX500 drives are unaffected as they have protections that prevent an attacker from accessing decrypted user data via a bypass of TCG password checking.

BitLocker

Background

When using BitLocker Drive Encryption to protect a self-encrypting drive, computers running Windows 8 and Server 2012 onwards will try to use hardware encryption by default. This may result in BitLocker users unintentionally using hardware encryption.

If the hardware encrypted drive loses power, such as when the system goes to sleep using Suspend-to-RAM, it needs to be unlocked again. BitLocker retains a copy of the secret key in memory in order to do this when resuming from sleep, which could allow an attacker with physical access to the device to obtain the key using Direct Memory Access (DMA).

In order to use hardware encryption on the start-up drive, the computer must boot natively from a modern version of Unified Extensible Firmware Interface (UEFI). Windows 10 also requires support for SecureBoot when the computer has a TPM 2.0 chip.

Modern computer processors typically support Advanced Encryption Standard New Instructions (AES-NI), which significantly improve the performance of software encryption. Newer Intel processors offer further improvements using XTS-AES compared to AES in CBC mode, making the performance impact less noticeable relative to using hardware encryption or no encryption at all.

Encryption Method

The command “manage-bde -status” can be executed from an elevated Command Prompt (or elevated PowerShell) to verify the encryption method in use for each volume.

For systems using hardware encryption, the value will begin with “Hardware Encryption” followed by an object identifier (OID) code that indicates the type of AES encryption in use.

If software encryption is in use, the value will be one of the following:

AES 128 with Diffuser

AES 256 with Diffuser

AES 128

AES 256

XTS-AES 128

XTS-AES 256

Certain versions of Windows do not support an Elephant Diffuser or XTS. These are mitigations to improve permutation in the AES block cipher mode that would otherwise allow practical attacks on disk encryption in Cipher Block Chaining (CBC) mode.

The drive encryption method used for software encryption can be specified under the relevant “Choose drive encryption method and cipher strength” setting for the operating system. These can be found under Administrative Templates > Windows Components > BitLocker Drive Encryption.

If removable drives need to be used with older versions of Windows the use of AES-CBC should be configured for compatibility. For example:

These settings only apply to BitLocker when using software encryption. Changes made to the encryption method will not be applied until BitLocker is turned off and the volume fully decrypted before BitLocker is activated again.

Prevent BitLocker from Using Hardware Encryption

Group Policy settings can be configured to Disabled in order to enforce the use of BitLocker’s software encryption. These can be found within Administrative Templates > Windows Components > BitLocker Drive Encryption:

Configure use of hardware-based encryption for fixed data drives

Configure use of hardware-based encryption for operating system drives

Configure use of hardware-based encryption for removable data drives

If the drive is already using BitLocker with hardware encryption (sometimes referred to as eDrive), switching to software encryption will require that BitLocker is turned off completely before enabling BitLocker again.

Encryption Vulnerabilities

Direct Memory Access (DMA) is possible from peripherals connected to some external interfaces such as FireWire and Thunderbolt. To help mitigate the disclosure of private keys held in memory, prevent the installation of specific device IDs and device setup classes, and disable new DMA device when the computer is locked. These settings can be found under Computer Configuration > Administrative Templates > System > Device Installation > Device Installation Restrictions.

Group Policy

Value

Prevent installation of devices that match these device IDs

Enabled: PCI\CC_0C0A

Also apply to matching devices that are already installed: Disabled

Prevent installation of drivers matching these device setup classes

Enabled:

{d48179be-ec20-11d1-b6b8-00c04fa372a7}

{7ebefbc0-3200-11d2-b4c2-00a0C9697d07}

{c06ff265-ae09-48f0-812c-16753d7cba83}

{6bdd1fc1-810f-11d0-bec7-08002be2092f}

Also apply to matching devices that are already installed: Disabled

Disable new DMA devices when this computer is locked

Enabled

Some devices may encounter issues when the “Disable new DMA devices when this computer is locked” Group Policy setting is set to Enabled.

Conclusion

Verify that devices relying upon BitLocker use software encryption on vulnerable drives.

Enable BitLocker with specific Group Policy settings to prevent the use of hardware encryption on all drives, and mitigate known direct memory attacks that could expose private keys. Windows 10 devices should enforce the use of XTS-AES for the software encryption method on fixed and operating system drives, as it was specifically designed for encrypting data on storage devices.