Many enterprise laptops use BitLocker to provide full disk encryption (FDE) to protect sensitive data from exposure if the laptop were stolen. But how adequate is the default implementation of BitLocker to protect data at rest in this scenario? The security of all encryption relies on protection of the key material. A common assumption is that since the BitLocker keys are stored in the Trusted Platform Module (TPM) the decryption process is secure. This is however only partly true as we will see in this article. First, we will look at the purpose of the TPM and how it works in relation to BitLocker.

What is the TPM?

The TPM is a hardware security component embedded in devices to provide cryptographic functions and is commonly used for tasks like encryption, digital signatures, and secure key storage. However, one of the key purposes of the TPM is to validate system integrity. To do this the TPM stores information such as hashes of the BIOS or UEFI firmware, bootloader, and/or hardware configuration in Platform Configuration Registers (PCRs) to identify any changes that could indicate a compromise. BitLocker uses the TPM to authenticate and ensure system integrity by verifying boot components before unlocking encrypted volumes.

A TPM can typically be configured in one of three ways:

• TPM Only: No user input required, only validates integrity checks
• TPM + PIN: The user must supply a PIN
• TPM + PIN + 2FA: The user must supply a PIN and a second factor (USB key, OTP)

In TPM-only mode, BitLocker does not require any user input, making the process seamless from the user’s perspective but less secure compared to configurations using a PIN or USB key. The TPM checks for system integrity, preventing access if the system has been tampered with, locking the encrypted volume until the system is restored to a known, secure state.

BitLocker uses several keys to protect the data. The data on the drive is encrypted using a full volume encryption key (FVEK). The FVEK is encrypted using the volume master key (VMK) and stored in the metadata on the disk. The VMK is stored inside the TPM and decrypted (unsealed) by the TPM when the appropriate conditions are met, such as the successful integrity check or being provided with the correct recovery key. This process allows the system to be re-keyed, for example if a recovery key has been exposed and needs to be replaced, without the need to re-encrypt the entire volume with a new FVEK.

The following diagram might help to visualize the flow of the inputs and the decryption of the VMK, FVEK, and subsequently the encrypted volume:

Where is the problem?

The problem lies in the fact that without an additional authentication factor if the system passes the integrity check the TPM will provide the unencrypted VMK which is then used to decrypt the FVEK and subsequently the encrypted data volume. The VMK is sent in cleartext by design and if we can gain access to this communication from the TPM we can read the VMK once it has been unsealed and use it to decrypt the data.

Surely the TPM standard should be designed to avoid this? Quite simply, yes it should, and it can. Part 1, Sections 19 and 21 of the TPM 2.0 Library Specification describes a feature called session-based parameter encryption. Using this feature the system generates a random value, derives a session key using a key derivation function, encrypts it with the public part of the TPM primary key, and transmits it to the TPM to initiate an encrypted session. However, this feature is not implemented by Microsoft.

Now that we understand how the TPM works, let us look at how practical it is to sniff the TPM bus, extract the VMK, and decrypt the disk. For the practical demonstration we will use a Dell Latitude E5470, a standard business laptop running Windows 11 Professional. This laptop, despite being a little older, was chosen because research revealed that it is representative of the technology used in the majority of corporate laptops using a discrete TPM chip implementing the TPM 2.0 specification in the same way as the current Dell Latitude/Precision series, and the popular HP Elitebooks which together make up a large proportion of the business laptop market. This TPM communicates via an SPI bus but the principles for an LPC bus are much the same.

Sniffing the TPM Bus

What tooling is required?

The equipment for this attack can be found in a well-equipped hardware hacking lab. The main tool we need to capture traffic on the TPM bus is a Logic Analyzer. The logic analyzer chosen for this demonstration was the DSLogic U3 Pro16. This device produced by Dream Source Labs in China fulfils the specifications required to sniff the SPI bus of the test laptop – Also, it can be purchased for a very reasonable price of around 300 EUR. This price point makes such attacks feasible even to attackers with limited resources.

Secondly, we need software to create and analyze the traffic capture. In this case, Dream Source Labs’ DSView, a fork of the popular Sigrok/PulseView software tailored for use with DSLogic, was chosen.

In addition to the logic analyzer itself the only specialized tooling required, unless the laptop provides PCB headers or pads that are easily accessible, are some logic probes. We used the PCBite tool for this demonstration but it would also be possible to use a basic SOIC8 clip whenever the flash chip is located on the same bus and easily accessible.

Last but not least, a small screwdriver and a spudger is usually all that is needed to open the laptop case.

Connecting to the Bus

The first task is to locate the TPM and any places we may be able to use to connect to the bus. In some cases, it may be possible to identify the chip with a visual inspection and/or an internet search. In most cases a schematic diagram or boardview file will be helpful, these can be found on the internet and often require membership to a forum or some payment. The legitimacy of the suppliers may be questionable as the distribution of such files is generally bound by intellectual property laws.

The location of TPM (1) on our example laptop is quite well documented and can be reached once the lower panel of the laptop case is removed. As the form factor of the TPM is quite restrictive it is practical that most connections for the logic analyzer can be made to the flash chip (2) that shares the same bus. To gain easier access to the flash chip we removed a small section of the plastic housing.

A little background information on the SPI bus will be helpful at this point for those unfamiliar with this protocol. The SPI (Serial Peripheral Interface) bus is a synchronous serial communication protocol used for short-distance communication, particularly in embedded systems. It operates in full duplex mode, allowing simultaneous data transmission and reception. The SPI bus comprises four main signals: Master Out Slave In (MOSI), Master In Slave Out (MISO), Clock (CLK), and Chip Select (CS). The clock signal is generated by the master device, which also selects the slave device by pulling the CS line low. Data exchange occurs in synchronization with the clock pulses, with the master and slave devices communicating via the MOSI and MISO lines, respectively.

The following is a pinout of the flash chip showing the relevant lines for connecting the logic analyzer:

Once the connection points were identified, the probes were attached and a capture was made while booting the laptop.

Analyzing the Data

The TPM contains various registers, the FIFO registers function as buffers between the host and the TPM during the exchange of command or response data. We can focus on the TPM_DATA_FIFO_0 register, which corresponds to the address 0xD40024 (the dark green line in the screenshot below).

The following screenshot is an example of the MOSI read request (dark green) and the response (light green/pink) of 2C on MISO:

By analyzing the stream of TPM_DATA_FIFO_0 responses the VMK can be identified by first locating the VMK header in the data stream, which matches the following regular expression:

2C000[0-6]000[1-9]000[0-1]000[0-5]200000

Once the header has been successfully located, the following 32 bytes will be the hexadecimal representation of the VMK.

Decrypting the BitLocker Volume

We can now use the VMK with dislocker to gain full access to the unencrypted filesystem. If the BIOS is configured to boot from USB we could use an operating system that is authorized for Secure Boot to perform this step. For this demonstration, the SSD was removed from the laptop and attached to a Linux host using a USB adapter, the following commands write the key to a file then decrypt and mount the BitLocker volume to /tmp/disk (replace /dev/sdXn with the appropriate device):

$ echo VMK_HEX_STRING | xxd -r -p > ./bitlocker.vmk

$ mkdir /tmp/fuse /tmp/disk

$ sudo dislocker-fuse -K ./bitlocker.vmk /dev/sdXn – /tmp/fuse

$ sudo ntfs-3g /tmp/fuse/dislocker-file /tmp/disk

After running these commands we have full access to the decrypted contents of the BitLocker volume, as shown in the following screenshot.

Feasibility and Risk

From this demonstration we can see that with a minimal set of tools and a small-time investment it is quite practical to access a drive encrypted with BitLocker. For an attacker the fun does not end there, with read and write access to the system drive much more is potentially possible than accessing the data stored on the device. Modifications can be made to gain a SYSTEM shell and with the system privileges we could move into network propagation by dumping system credentials or certificates to gain access to the corporate network via VPN or other remote access tools. Let us look at this exploit in terms of the cost-benefit ratio for an attacker. The costs associated with this attack are quite low. The main monetary cost being for a logic analyzer, which is found in any well-equipped hardware hacking lab or purchased for around 300 EUR, and a time investment that in most cases would not exceed more than a few hours and in some cases much less. The benefit side of the equation will be dependent on the data stored locally and the potential to use the laptop as an entry point to the corporate network.

Remediation

This type of attack can be avoided by implementing a second factor for pre-boot authentication, either a user PIN and/or USB Startup Key. Without this additional factor the VMK will not be unsealed by the TPM.

References

• Dell Response to TPM Interposer BitLocker Research:
  https://www.dell.com/support/kbdoc/en-us/000222428/dell-response-to-tpm-interposer-bitlocker-research
• Microsoft – BitLocker Countermeasures:
  https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/countermeasures
• GitHub – dislocker:
  https://github.com/Aorimn/dislocker
• Trusted Computing Group: TPM 2.0 Library
  https://trustedcomputinggroup.org/resource/tpm-library-specification/
• Trusted Computing Group: TPM 2.0 Specification – Part 1
  https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-1-Architecture.pdf

Jonathan Prince

Jonathan joined NVISO as a Senior Security Consultant in 2019 and is part of the software security assessment team.​ ​With more than 10 years professional experience in the IT industry  Jonathan has worked extensively in the topics of security assessments, software development lifecycle, asset management, system hardening, and infrastructure design. ​

​Jonathan’s main areas of focus within NVISO are smart contract auditing, software assessments, and mainframe security.