[Nextgrid]

If the device is stolen it can still enforce OS-level authentication (including potentially phoning home, invalidating its access to remote resources, or erasing itself), except now you can't bypass it by rebooting and running chntpw.

Will this stop a dedicated attacker? Probably not, although a fTPM with an up to date OS would require the attacker to find an exploit for this machine's early boot firmware (UEFI, etc) or burn a Windows zero-day, both of which are very costly.

It does however prevent your casual thief from watching a YT video "how to reset windows password using linux live cd" and then getting access to your sensitive data (browser's saved passwords, etc), so it's a major improvement.

[vlovich123]

I prefer to require entering a master password on boot manually and then configuring the OS to auto login to my non root user (with a different password than the disk). The longer and more complex your dependency chain for security, the more opportunity for it to be compromised. The encrypted “password on boot” partition then contains the keys to mount the other disks.

I’d really like Apple’s model on my machine where the root image is just the stock OS image unencrypted and the co-processor owns the responsibility of managing IO (and done efficiently) using my master key. TPM seems like it misses the mark from that perspective.

[notquiteright]

Using a decryption password on boot is less secure than TPM + measured boot/secure boot. Specifically, it’s vulnerable to a two-touch attack. In the first touch, the attacker replaces your bootloader with one that looks identical but steals your password. On the second touch, they now use the password to steal your data.

[acdha]

If the attacker can install a custom boot loader the system is already defective by design.

[sudosysgen]

If the attacker can replace your bootloader, why can't they just get the decryption key from the kernel later? And if you did have Secure Boot, then using a password with encryption at rest is just as secure : you can't change the bootloader and you can't change the OS (since it's encrypted), so you can't exfiltrate the password. The end result is that the TPM doesn't have a practical benefit.

[lostmsu]

The bit about "two touches" seems to imply physical access, so in absence of TPM the attacker can replace your bootloader with little effort vs with TPM they'd need to break TPM.

[saagarjha]

You can fix this by asking for the password before letting the attacker replace the bootloader.

[lostmsu]

Sorry, I missed the bit about Secure Boot.

Yes, with Secure Boot and password your data is safe. But you have to type the password to boot your system, which is impractical for remote and headless systems, or even local systems that need to be available remotely.

[vlovich123]

You would still use the TPM to verify the software chain. But don’t use the TPM to Auto unlock disks. That’s the part that feels like a bad idea

[zamalek]

The issue is that data disks and system disks get conflated. For the system disk (anything outside of /home) you generally only care about signing - which FDE does as a side-effect. Each user should have their own disk/partition/subvolume with a distinct key that is retrieved from the PAM.

This achieves two things: I know that I am typing my password into the OS that I or a trusted third party compiled (not one planted by a hacker), and my home directory gets decrypted as part of my normal login routine.