What actually happens when someone steals your LUKS-encrypted disk

Chitra Jasuja — Sun, 09 Aug 2026 18:31:08 +0000

I set up TPM auto-unlock on my laptop a while back — systemd-cryptenroll,
bind to a couple of PCRs, disk unlocks silently on boot, no more typing a
passphrase every morning. Nice quality-of-life win.

Then a friend asked me a question I didn't have a great answer to: "okay but
if someone actually steals the laptop, doesn't the TPM just... hand over the
key for them too?"

I didn't like that I had to go verify the answer instead of just knowing it.
So I did, and it's worth writing down because the mental model most people
(including past me) have of "TPM-bound disk encryption" is slightly wrong in
a way that matters.

The setup

Quick background for anyone not knee-deep in this already: LUKS doesn't
encrypt your disk with your passphrase directly. There's one randomly
generated master key that does the actual encrypting, and your passphrase
(or a TPM-released secret, or a recovery key) only ever wraps and unwraps
that key. You can have several of these "doors" into the same master key
at once — a daily passphrase, a TPM-sealed slot, a recovery key on paper —
and disabling one doesn't touch the others.

The TPM slot works by sealing a secret: the TPM will only decrypt it back
if the machine's current boot-time measurements (PCRs — Platform
Configuration Registers) match what they were when you sealed it. Those
measurements are a hash-chain of everything that ran during boot — firmware,
bootloader, kernel. Change any of it, the hash changes, the TPM won't unseal.

So what does an attacker actually get?

Say the laptop gets stolen and someone pulls the drive, plugs it into their
own machine via a USB adapter. What do they have?

The full LUKS2 header, including the TPM-sealed keyslot's blob. That blob
isn't secret in the sense of being hidden — cryptsetup luksDump on the
stolen disk will happily show them that a TPM2 token exists. What they don't
have is a way to use it, because unsealing requires the original TPM chip's
Storage Root Key — an asymmetric key that's generated inside that specific
chip and is designed by the TPM 2.0 spec to never leave it in plaintext form.

Plug the disk into a different machine, and you have the sealed blob sitting
next to a completely different TPM that has zero record of the key that
sealed it. The unseal operation just fails. Not "fails because of a wrong
guess" — fails because the cryptographic material needed doesn't exist
anywhere outside the original chip.

I tested this directly: took a LUKS2 volume with a TPM2 token enrolled,
tried opening it against a different machine's TPM.

$ sudo cryptsetup open --type luks2 --token-id 1 /dev/sdX victim_disk
Failed to activate using token 1.

Exactly as expected. The metadata is visible, the mechanism is not
exploitable.

Okay, so TPM-binding solves everything?

No — and this is the part that actually matters. TPM-binding solves a
specific threat: a cold, powered-off, stolen drive. It does basically
nothing against a different, much more common threat: someone getting
access to your running or suspended session.

If your laptop is asleep (not powered off) and someone gets past your lock
screen — guessed password, shoulder-surfed PIN, whatever — the TPM will
unseal the key for them just as happily as it does for you every morning.
That's not a bug, that's the entire feature. The TPM doesn't know who's
asking, it only checks whether the boot state matches. A logged-in session
on a stolen-but-running machine has already crossed that boundary.

So the actual protection story is:

Cold stolen disk, no login → TPM-binding does its job, drive is inert without the original chip
Warm/suspended machine, attacker has your login → TPM-binding buys you nothing, session lock and login strength are what's actually carrying the weight
Offline brute-force of a weak passphrase slot → TPM-binding doesn't strengthen this either, it's a completely separate keyslot

None of this means TPM auto-unlock is a bad idea — it's genuinely useful
convenience with a real security property attached to a real threat model.
It just isn't the blanket "my disk is safe now" button it's easy to assume
it is. The actual thing doing the heavy lifting against a stolen-but-running
machine is still your login screen and however aggressively your machine
locks/suspends.

What I'd actually recommend if you're setting this up

Keep at least one strong passphrase keyslot that doesn't depend on the TPM at all — if the chip gets cleared or a firmware update shifts your PCRs, this is what saves you
Bind to a sane, minimal PCR set (I use PCR 0 + 7 — firmware and Secure Boot policy) rather than pinning to every possible measurement, or you'll be re-enrolling after every kernel update
Configure actual suspend-to-RAM or hibernate on lid close, not just a screen dim — if the session never sleeps, TPM-binding's threat model doesn't really apply to your actual usage pattern
Keep an offline recovery key somewhere that isn't "a file on the same laptop"

*I ended up writing a longer, illustrated version of this covering the full
chain — UEFI Secure Boot, TPM PCRs, Intel vs AMD implementations, and the
LUKS2 keyslot internals — as The Linux Secure Boot & Full-Disk Encryption
Handbook.

This post is the short version of chapter 7.
Happy to answer questions about any of this in the comments.*

DEV Community: Chitra Jasuja

What actually happens when someone steals your LUKS-encrypted disk

The setup

So what does an attacker actually get?

Okay, so TPM-binding solves everything?

What I'd actually recommend if you're setting this up