HP ThinPro TPM Disk Encryption Flaw Lets Attackers Extract LUKS Keys
Brief
HP ThinPro’s TPM-backed disk encryption can be bypassed by a physical attacker who modifies unencrypted boot files, allowing extraction of the LUKS key protecting device data.
Researcher Darren McDonald said the issue affects ThinPro 8 and 9 deployments on HP thin clients, undermining the assumption that a TPM seal alone protects a removed or stolen drive against offline access attacks.
The flaw stems from incomplete boot chain measurement. ThinPro stores its operating system on a LUKS2-encrypted btrfs partition and uses a custom utility, hptc-tpm-tool , to seal the disk key within the Trusted Platform Module.
During startup, an initramfs key script requests the TPM released key and supplies it directly to cryptsetup , ordinarily avoiding storage of the secret on disk.
HP ThinPro TPM Flaw
However, the TPM policy reportedly binds the sealed key only to PCRs 0, 2, and 4.
All credited sources
Highest-trust first. Dates are the publisher's original publish time.
HP ThinPro TPM Disk Encryption Flaw Lets Attackers Extract LUKS Keys
A security researcher has disclosed a boot-chain weakness in HP ThinPro 8 and 9 that could allow attackers with physical access to a thin client to extract its LUKS disk-encryption key .
The issue affects HP thin clients in which LUKS2 protects the operating system’s encrypted root partition, and the decryption key is sealed inside the device’s Trusted Platform Module (TPM).
While this design is intended to prevent data theft from removed storage drives, the researcher found that the TPM policy does not fully validate the software loaded during Boot.
HP ThinPro uses a custom utility, called hptc-tpm-tool, to retrieve the LUKS key from the TPM during startup. An initramfs script named unseal_key requests the key and passes it directly to cryptsetup, which unlocks the encrypted root partition.
HP ThinPro TPM Disk Encryption Flaw
However, the TPM key is reportedly sealed only to PCR 0, PCR 2, and PCR 4. These registers measure BIOS firmware, option ROMs or UEFI drivers , and the GRUB bootloader binary.
They do not measure GRUB configuration commands, the Linux kernel, or the initramfs that GRUB loads. This creates a significant gap.
An attacker cannot simply replace the GRUB binary without changing PCR 4 and blocking key release. But they can modify the unencrypted initramfs, including the shell script that unseals the key, without altering the PCR values the TPM checks.
According to the AmberWolf disclosure , a modified initramfs can copy the recovered LUKS key to the unencrypted BOOT partition before normal startup continues.
On the next Boot, the TPM treats the system as trusted because the firmware and GRUB measurements remain unchanged. The device then starts normally, while the attacker can later retrieve the exposed key from the drive .
The attack requires local physical access and the ability to remove or modify the M. 2 SATA storage device. No soldering, specialized hardware, or advanced reverse engineering is required.
HP ThinPro TPM Flaw Lets Physical Attackers Extract LUKS Disk Encryption Keys
HP ThinPro’s TPM-backed disk encryption can be bypassed by a physical attacker who modifies unencrypted boot files, allowing extraction of the LUKS key protecting device data.
Researcher Darren McDonald said the issue affects ThinPro 8 and 9 deployments on HP thin clients, undermining the assumption that a TPM seal alone protects a removed or stolen drive against offline access attacks.
The flaw stems from incomplete boot chain measurement. ThinPro stores its operating system on a LUKS2-encrypted btrfs partition and uses a custom utility, hptc-tpm-tool , to seal the disk key within the Trusted Platform Module.
During startup, an initramfs key script requests the TPM released key and supplies it directly to cryptsetup , ordinarily avoiding storage of the secret on disk.
HP ThinPro TPM Flaw
However, the TPM policy reportedly binds the sealed key only to PCRs 0, 2, and 4. Those registers measure BIOS firmware , option ROMs or UEFI drivers, and the GRUB binary.
They do not measure GRUB configuration commands, the Secure Boot state, the Linux kernel, the initramfs image, or scripts loaded by the bootloader after GRUB has launched.
That omission gives an attacker with physical access a way to replace or alter the initramfs without changing the measured PCR values.
McDonald found that the unseal_key script within the initramfs can be modified so that, once the TPM releases the LUKS key, it writes a copy to the unencrypted BOOT partition before continuing the normal decryption process.
The affected thin client then boots normally, with no obvious warning displayed to the local user. The attacker can subsequently remove the M. 2 SATA drive again, retrieve the saved raw key material from the BOOT partition, and open the encrypted partition elsewhere.
This exposes device configuration data, certificate and credential stores, and password hashes associated with root and user accounts.