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.

What problem is this solving though? The post says they're doing this to avoid typing passphrases. Why would you want the private key hidden in the tpm chip of that device? How will you decrypt if the laptop goes bust or if you move the drive elsewhere?

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.

Fairly sure that if the correct GPOs are set, there is no need for any shell commands needed for a TPM PIN enrollment.

Windows and macOS both can do FDE with good UI/UX compared to Linux.

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.

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.

> 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 (as would happen when you put the drive in another device), the bootloader will prompt for a passphrase just like it did before, once entered it will decrypt from another keyslot.

> I always struggle to understand the point of using disk encryption with TPM, as opposed to the disk encryption with LUKS + passphrase

What if you expect the machine to reboot, unattended, after a power outage for instance?

Amen.

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)

tpm2totp used to do this, and it also eliminated the need to divulge the secret used to unlock the TPM, I now see that it has not seen a commit in 2 years.

I also hear mjg59 is looking into encrypted swap hibernation support, so there's a slim chance there will be some development on the system-attestation front.