Sealing to a reasonable subset of PCRs (ie, not just 7 like the article) is reasonably strong against point-in-time evil maid, no?
Like, in Evil Maid Scenario 1, where the Evil Maid only has one-time access, if you've sealed to say 0,2,4,7,9 , or 7 and 15 with a reasonable setup for what gets extended into 15, the Evil Maid's Fake PIN Entry Software would _not_ validate in the secured boot configuration and couldn't actually unseal the TPM, only coerce you into entering your PIN. Then the Evil Maid would have to physically return to your "correct" boot state with the PIN to unseal the disk, no?
(this is all modulo firmware and early boot exploits, of course, since in that case the attestation could also be forged also)
I would call out if it is a solder on TPM (or worse a removable module) MITM attacks work against the TPM. (I don't know why, but apparently new dell servers are still shipping with solder on TPMs and having the BIOS/UEFI firmware measure into that instead of just using the AMD EYPYC CPU's fTPM.) TPM isn't actually going and measuring anything on its own, it just gets PCR extend commands containing hashes sent over from the CPU that it has to trust are meaningful. If you can watch the bus (usually just SPI) it would be trivial to monitor the traffic to the TPM during a reboot and watch the hashes it is expecting to see, at least for the boot artifacts. So, IMO against physical access the PCRs aren't doing a whole lot, and the whole thing is resting on a PIN. (Obviously this is a huge problem for servers, where a PIN is probably not in use.)
For what it's worth, TPM supports session encryption, but the compatibility is poor due to bad TPM implementations (which is a whole extra can of worms), so it isn't enabled by default in most configurations. If this threat model is meaningful to you (which it probably is if you're using TPM-backed FDE), it's worth looking into what it would take to set up (and switch to fTPM if possible).
Although, if anyone wants an RE project, I've always been interested in reversing the ME <-> CPU bus on Intel to see if the ME-embedded TPM is still vulnerable to snooping. And of course all of this is still highly vulnerable to any early-boot / root of trust exploit (ie against Boot Guard / PSB or horrible UEFI firmwares).
Extraordinary how Linux continues to be 20 years behind Microsoft and Apple when it comes to FDE. This is a hilariously stupid level of complexity for something that should have a universal solution across distros by now.
This is literally a one click process in Windows (plus a couple shell commands to enable TPM+PIN).
I'm not disparaging the author in any way — he's merely documenting the stupidity.
On both my Fedora laptop and on my MacBook, I have to enter a password at boot to unlock the hard drive, and both had similar complexity to set it up (in Fedora I clicked a button and entered a password during the install, on Mac I clicked a button and wrote down a backup key after the install).
I think this is specifically for the TPM2 integration, which isn’t required for FDE. But I assume it makes it smoother. System updates that requires multiple reboots for example are more annoying on Fedora, since every reboot requires re-entering the password, while on Mac I just login after the final reboot.
FDE without TPM requires the passphrase to have as many bits of security as you want the encryption to have. With a TPM you can have something as short as a PIN, since the TPM can limit the rate at which password attempts are made. I assume most users are satisfied with the weak security implied by a short passphrase, but a dedicated attacker could likely crack it.
FDE uses a key derivation function to limit the rate at which offline password attempts can be made. Not as limited as a TPM can be but not unlimited either and you can adjust it depending on how long you want to wait every time you unlock.
Has nothing to do with distros. This is you encrypting your disk for the kernel to open during boot. It literally prompts you normally when it hits the step where it attempts to mount the main partition. The way Linux does it is far more flexible and secure because the keys aren't sent to some third party and no one can unlock it without your keys. You are free to use anything to sign the LUKS partition besides a TPM or some silly pin like a Yubikey or whatever the hell you want.
It's all luks2 and kernel negotiation. You use fdisk or similiar to partition and then the kernel mounts it based on the bootloader config.
Literally the only thing distros can do is give you options during install for the partitioning but that is a personal decision for people and it's basically remaking gparted.
I mean, Linux has perfectly good FDE - just the user has to type in their password at boot, no TPM involved.
And it's been possible to get Windows-style self-unlocking FDE for 10+ years, such as by using Ubuntu Core - it just costs a bit, and most users aren't willing to pay $$$ to type one less password.
The design of the TPM makes much more sense for a closed-source operating system, where making it impossible to run a non-microsoft-signed OS protects you against rootkits. Open source OSes don't get that benefit, and the remaining benefits are very minor (and come with big downsides) so I can see why open source developers weren't in a hurry.
> The design of the TPM makes much more sense for a closed-source operating system
I don't think that's the case. The great thing about TPMs is that they measure what's on your system. As long as you modify things properly, your changes get measured and stored in the TPM.
Secure Boot is the more closed-sourced way. By default it relies on Microsoft keys unless you enroll your own and sign your stuff.
Secure Boot also works with Linux, no self-enrolled keys required for poular distros.
TPM measured boot is supported, but it’s a bit fussy to set up using traditional Linux boot, because the firmware, kernel, kernel command line, initrd, grub executable, grub environment, and the complete sequence of grub commands all need to be measured, and some of these things can change for valid reasons other than the obvious case of system updates or reconfiguration (e.g., the Red Hat grub-boot-success mechanism which sets a grub environment variable 2 minutes after a successful boot, so a reboot during or shortly after boot is enough to make measurements taken with this variable set fail).
Also, as in any auto-unlock scenario, the boot process all the way to the login prompt needs to be secured against any interruption that may enable the user to get unauthenticated system access after the disk is unlocked.
Doesn't MS use bitlocker? Or did for a long time, and haven't serious vulns been found in it? If so, I'm not even sure it's a valid comparison. One is real encryption the other is crypto-theater.
Also, isn't the insanity due to MS' influence? They were rumored to do this with influencing the UEFI spec, making Linux less desirable because it was so difficult to dual boot or even single boot UEFI when it came out. This conveniently helped windows hold market share (I'm going back to ballmer Linux=cancer days).
It would stand to reason MS would use their influence to make TPMs insane for end users to manage in Linux but a breeze in windows for the same reason. This is presuming we both agree that MS exerts control over hw manufacturers, I think this is clearly the case.
TPMs aren’t insane to manage in Linux for any technical reason, distros have simply not yet implemented user-friendly tools for automatically managing measured boot.
This works equally well on Debian 13, but I found that installing Dracut (which will be the default from Debian 14 onwards) made the whole process smoother.
To counter some of the (valid) privacy concerns around TPM unlocked FDE, one big benefit is when it comes to decommissioning physically secure machines. If you aren’t concerned about the evil maid scenario and have reason to avoid network based unlocking, TPM unlocked FDE keeps your machines remotely rebootable while still allowing you pull a disk and send it for secure shredding at server EOL. That is to say, if your scenario is “encrypted at rest on a physically secure and trusted server” (more concerned with the storage medium alone), it’s a good fit. It means you’re not reliant on the OEMs opaque secure erase functionality.
I always struggle to understand the point of using disk encryption with TPM, as opposed to the disk encryption with LUKS + passphrase which you remember
With TPM you depend on it so much. What if it breaks? Should I backup the recovery key beforehand? My life has enough keys already
Moving the disk to a new laptop also becomes pain
> What if it breaks? Should I backup the recovery key beforehand?
TPM unlocking uses a keyslot in a LUKS container, just like your passphrase does. There are 10 keyslots, so it's not mutually exclusive operation. If TPM doesn't unlock LUKS, the bootloader will prompt for a passphrase, once entered it will decrypt from another keyslot.
I don't expect my machine to reboot unattended. I immediately imagine the government prying it from my hands, booting it and then searching for vulnerabilities in lightdm / dumping the RAM (just checked and I have a line "TSME enabled" in kernel logs so dumping data from the memory sticks probably will be useless)
---
I've never thought much about secure unattended reboots, thank you for suggesting
On Fedora I implemented TPM2 unlock with strong PCR pins selection with ease. For the ocasional PCR mismatch (on firmware upgrades mostly), I have password, recovery code and even a FIDO2 USB key as options. LUKS2 + Systemd make it so easy to implement. Folks forget that LUKS2 support many unlock slots and methods.
I've used a Tang server to provide encryption keys. Since I don't take my laptop out of my home much, I like the idea that only a passphrase can unlock my machine outside of my home network. It works well for home servers also, and I don't need a bunch of secure boot and storage pcr configs that get mucked up during bios updates.
My model of defense is.if someone is in my house taking all my stuff, I'm probably owned though a smash and grab yields nothing. Plan accordingly for your needs I guess.
33 comments
[ 1.3 ms ] story [ 26.5 ms ] threadLike, in Evil Maid Scenario 1, where the Evil Maid only has one-time access, if you've sealed to say 0,2,4,7,9 , or 7 and 15 with a reasonable setup for what gets extended into 15, the Evil Maid's Fake PIN Entry Software would _not_ validate in the secured boot configuration and couldn't actually unseal the TPM, only coerce you into entering your PIN. Then the Evil Maid would have to physically return to your "correct" boot state with the PIN to unseal the disk, no?
(this is all modulo firmware and early boot exploits, of course, since in that case the attestation could also be forged also)
Although, if anyone wants an RE project, I've always been interested in reversing the ME <-> CPU bus on Intel to see if the ME-embedded TPM is still vulnerable to snooping. And of course all of this is still highly vulnerable to any early-boot / root of trust exploit (ie against Boot Guard / PSB or horrible UEFI firmwares).
This is literally a one click process in Windows (plus a couple shell commands to enable TPM+PIN).
I'm not disparaging the author in any way — he's merely documenting the stupidity.
I think this is specifically for the TPM2 integration, which isn’t required for FDE. But I assume it makes it smoother. System updates that requires multiple reboots for example are more annoying on Fedora, since every reboot requires re-entering the password, while on Mac I just login after the final reboot.
The process is wholly dependent on bootloaders, systemd versions, and a bunch of other version-specific tooling.
Which none of the distros can ever agree on, so there are 50 variations of implementing disk encryption.
Literally the only thing distros can do is give you options during install for the partitioning but that is a personal decision for people and it's basically remaking gparted.
please have an llm explain it to you.
And it's been possible to get Windows-style self-unlocking FDE for 10+ years, such as by using Ubuntu Core - it just costs a bit, and most users aren't willing to pay $$$ to type one less password.
The design of the TPM makes much more sense for a closed-source operating system, where making it impossible to run a non-microsoft-signed OS protects you against rootkits. Open source OSes don't get that benefit, and the remaining benefits are very minor (and come with big downsides) so I can see why open source developers weren't in a hurry.
I don't think that's the case. The great thing about TPMs is that they measure what's on your system. As long as you modify things properly, your changes get measured and stored in the TPM.
Secure Boot is the more closed-sourced way. By default it relies on Microsoft keys unless you enroll your own and sign your stuff.
TPM measured boot is supported, but it’s a bit fussy to set up using traditional Linux boot, because the firmware, kernel, kernel command line, initrd, grub executable, grub environment, and the complete sequence of grub commands all need to be measured, and some of these things can change for valid reasons other than the obvious case of system updates or reconfiguration (e.g., the Red Hat grub-boot-success mechanism which sets a grub environment variable 2 minutes after a successful boot, so a reboot during or shortly after boot is enough to make measurements taken with this variable set fail).
Also, as in any auto-unlock scenario, the boot process all the way to the login prompt needs to be secured against any interruption that may enable the user to get unauthenticated system access after the disk is unlocked.
Also, isn't the insanity due to MS' influence? They were rumored to do this with influencing the UEFI spec, making Linux less desirable because it was so difficult to dual boot or even single boot UEFI when it came out. This conveniently helped windows hold market share (I'm going back to ballmer Linux=cancer days).
It would stand to reason MS would use their influence to make TPMs insane for end users to manage in Linux but a breeze in windows for the same reason. This is presuming we both agree that MS exerts control over hw manufacturers, I think this is clearly the case.
You have no idea what is inside the TPM chip and its vulnerabilities.
With TPM you depend on it so much. What if it breaks? Should I backup the recovery key beforehand? My life has enough keys already Moving the disk to a new laptop also becomes pain
TPM unlocking uses a keyslot in a LUKS container, just like your passphrase does. There are 10 keyslots, so it's not mutually exclusive operation. If TPM doesn't unlock LUKS, the bootloader will prompt for a passphrase, once entered it will decrypt from another keyslot.
What if you expect the machine to reboot, unattended, after a power outage for instance?
---
I've never thought much about secure unattended reboots, thank you for suggesting
My model of defense is.if someone is in my house taking all my stuff, I'm probably owned though a smash and grab yields nothing. Plan accordingly for your needs I guess.