Why PureBoot is superior security

Firmware PureBoot/Heads
1

AmberWolf Research presented last month at DC34 an attack against some HP ThinPro models that I think deserves to be discussed in the context of PureBoot (coreboot/HEADS boot stack.)
Their Proof of Concept shows a UEFI critical flaw in the boot chain’s security, which PureBoot would have detected easily as tampering.

TL;DR: if you can steal a ThinPro 8 or 9, although the root partition is LUKS encrypted one can recover the TPM-sealed DUK (Disk Unlock Key) and decrypt all the data.

A blog post at: https://blog.amberwolf.com/blog/2026/august/hp-thinpro-tpm-sealed-disk-encryption-that-only-measured-half-the-boot-chain/ describes the attack (sorry, won’t preview in a box…)

The problem:

HP ThinPro 8 and 9 encrypt the root partition with LUKS and seal the key to the TPM. This is meant to keep the data safe if an attacker gets physical access to the disk. It does not, due to a rather large gap in the measurement of the boot chain.
Examining the boot loader showed the TPM seal only binds the key to PCRs that measure the BIOS, the option ROMs, and the GRUB binary. That trusted GRUB binary then loads a kernel and an initramfs that nothing measured at all.

If there is no measurement of what the bootloader loads - critical binaries can be forged in order to unveil the DUK and store a copy to the unencrypted /boot partition.

The attack:
It involves patching a particular shell script inside the initramfs: unseal_key

  • Remove the M.2 SATA drive, attach it to your machine
  • Mount the unencrypted /boot partition, unpack the initramfs
  • Patch unseal_key, repack, write it back

Patched script
Patched script1780×506 53.9 KB

  • Reinstall the drive, power the device on
  • PCRs 0, 2, 4 are unchanged, so the TPM unseals the key
  • The patched script writes the key to .luks_key on /boot
  • Pull the drive again, read the key, cryptsetup luksOpen the encrypted partition

No soldering, no reverse engineering, no exotic anything.

This attack would not have succeeded with PureBoot or any other coreboot/HEADS boot stack. Of course, the initrd in the unencrypted /boot partition can be unpacked and any script can be modified; but this sort of tampering would inevitably be caught because anything inside that partition that was modified after the last time it was signed by the security dongle, would alert the user of that change.

2

An alternative attack path could be more in the nature of an Evil Maid Attack: If you temporarily have access to the device … take an imaged copy of the encrypted drive for yourself, patch the boot partition to export the LUKS master encryption key (no need to take advantage of any flaws in the detailed implementation), leave the owner with the device and wait for it to be unlocked by the owner, at which time you will receive a copy of the master encryption key. Now decrypt your copy.

There are advantages and disadvantages of the alternative approach. A disadvantage is that a sophisticated device owner might prevent or detect the exfiltration of the master encryption key. An advantage is that you have stolen the contents of the drive but the owner is potentially unaware of it - which may increase the value of the contents of the drive.

Either way though, as you say, there has to be integrity in the whole boot chain.