The important part in the parent is "that don't need a user password". You just said you had to supply a (user) password.

With a TPM you can set it up that your disk is unlocked automatically, but only if no-one changed anything in the signed boot chain. This is the default with Bitlocker on Windows and is also possible on Linux, though somewhat more finicky.

but why bother? I can fit enough entropy in my head to make my hard drive uncrackable, and I can back up my data even if some chip breaks.

It's just added complexity and corporate control so people can use worse passwords

But most people don't want to enter a password, and if you make people enter a password too much, they'll choose terrible passwords and put them on a sticky note. Windows Hello can only be done securely with a TPM. A server that I want to turn back on all by itself after a power outage can only be done securely with a TPM.

I want a TPM in my computer so I can have the security and convenience. Yes, it's another point of failure. But I need backups in case the hard drive fails anyway. And besides, the OS can be designed so I can enter a password if I need to use the drive without the TPM.

>Windows Hello can only be done securely with a TPM

I think in general biometrics are in the same ballpark as low-entropy passwords. IDK, I personally have no faith in trusted computing hardware because it can be broken with the right equipment. You're right that it can be used alongside ordinary security measures, but I just think it encourages putting your eggs into a cryptographicially-weak hardware-strong basket (which represents a downgrade because crypto is stronger than hw).

>A server that I want to turn back on all by itself after a power outage can only be done securely with a TPM.

Can you describe how this prevents a MITM attack? I assume you mean a remote server? I've heard of colocation setups like this, but I think they rely on a couple of unstated assumptions.

> >A server that I want to turn back on all by itself after a power outage can only be done securely with a TPM.

> Can you describe how this prevents a MITM attack? I assume you mean a remote server? I've heard of colocation setups like this, but I think they rely on a couple of unstated assumptions.

I'm not sure what you mean by prevent a MitM attack, unless you're worried about someone with probes MitM-ing your TPM-CPU connection in the DC.

You can bind a TPM to measurements on the host (let's say for argument's sake you want Secure Boot state, Option ROM state, and UEFI state), then configure the OS to ask the TPM for the (or rather, a) decryption key during boot.

The TPM will check that the state(s) you bound to is (are) the same as when you bound them, and if so it will give the OS the key. Your disk is encrypted, but the boot process is automatic/unattended, as well as completely contained within the server chassis.

There are ways to attack this hypothetical setup, buuuuut there are ways to attack remotely entering your disk password as well, and bear in mind that denial of service is a security vulnerability. Tradeoffs.

I agree that biometrics are in the same ballpark as low-entropy passwords, which means their security relies on avoiding offline attacks. My ATM card is protected by a 4-digit pin. That's perfectly secure, because the ATM network won't let you enter a wrong pin more than a single-digit number of times before locking the account.

Windows Hello allows you to log in with a 6-digit pin. That's perfectly secure, because the TPM lets them design a system where you can't do an offline attack on the pin. Too many wrong entries and you'll need to use your password.

I doubt there's more than two dozen bits of entropy provided by finger print readers or facial recognition authentication, but you can make an acceptably secure login experience with it because, again, the TPM lets you prevent offline attacks.

But without password, anybody can physically access the device and exfiltrate data. That is even easier than regular password protection, where the storage medium would have to be removed or a live OS would have to be booted.

The risk is data leakage. With a TPM and no password, there is no data leakage protection.

Passwordless boot with a TPM means the software can control what secrets it gives out. Yeah, if you boot to a desktop operating system and auto-login as an admin user, that doesn't leave things very secure, but that's not the only scenario.

Consider a server. It can have an encrypted hard drive, boot with the TPM without a password, and run its services. In order to steal data from it, you need to either convince software running on the server to give you that data, or you need to do some sort of advanced hardware attack, like trying to read the contents of DRAM while the computer is running.

There are other use cases too, like kiosks, booting to a guest login, corporate owned laptops issued to employees, allowing low-entropy (but rate limited) authentication after booting, to name a few.

> Am I missing something? My disk is encrypted. If they take it apart, they need my password to crack the encryption.

You’re not protected from an evil maid attack. An attacker with physical access could make your device boot their own payload to capture your encryption key and install a rootkit.

So what happens when they use their physical access to turn off secure boot or just replace the component/device with one that looks the same, prompts for your password and sends it to them?

You get a prompt to enter Bitlocker recovery key if you turn off Secure boot in BIOS.

That's Windows doing that, which they've just compromised and then configured to display only the normal login prompt but send your credentials to the attacker.

They can also decrypt your hard drive by doing the same thing without modifying the original machine by just stealing it and leaving you a compromised one of the same model to also steal your password.

If evil maid attack, and you see this prompt, you a) re-enable secure boot, if did not work b) throw away the device.

In any case data stays secure.

Edit: Hmm, you have a point, how do I know secure boot was disabled in the first place? Anyway, still works for servers and unattended reboots.

No, GP is misinterpreting Windows's message. It prompts for a recovery key because the TPM is bound to, among other things, Secure Boot == enabled. When Secure Boot is disabled, the TPM notices that and refuses to release the key, that's how you know to reënable Secure Boot or throw away your device.

The fact that Windows is compromised does not make it capable of extracting secrets from the TPM, though maybe a naïve user can be convinced to enter the recovery key anyway...

> When Secure Boot is disabled, the TPM notices that and refuses to release the key, that's how you know to reënable Secure Boot or throw away your device.

But the attacker isn't trying to get the key from the TPM right now, they're trying to get the credentials from the user. It's the same thing that happens with full disk encryption and no TPM. They can't read what's on the device without the secret but they can alter it.

So they alter it to boot a compromised Windows install -- not the original one -- and prompt for your credentials, which they then capture and use to unlock the original install.

They don't need secure boot to be turned on in order to do that, the original Windows install is never booted with it turned off and they can turn it back on later after they've captured your password. Or even leave it turned on but have it boot the second, compromised Windows install to capture your credentials with secure boot enabled.

How suspicious are you going to be if you enter your credentials and the next thing that happens is that Windows reboots "for updates" (into the original install instead of the compromised one)?

So this attack is to steal my Windows password or Windows Hello credentials, but doesn't get my encryption key...? That's...not ideal, but I think you'll see it's an improvement over unencrypted disks (again, TPMs are for people who can't be bothered to set a strong password).

And again this presupposes that you can disable Secure Boot, boot a malicious OS from another drive, fool the user into entering their password, automatically reboot, enable Secure Boot, boot into the legit OS, then come back later and have the ability to boot the OS yourself and log in as the user (because again, you don't have the decryption key, you have the user's login credentials).

You are also presupposing what the TPM is bound to. I don't use Windows, but using systemd-cryptsetup I could configure a TPM to bind to the drives in the system; in this way, it will refuse to boot my legit OS while your malicious disk is installed (well, it will demand a recovery key). Again, setting off alarm bells, and if I discover the disk with my recorded credentials before you can physically access it, I can just destroy it.

> And again this presupposes that you can disable Secure Boot, boot a malicious OS from another drive, fool the user into entering their password, automatically reboot, enable Secure Boot, boot into the legit OS, then come back later and have the ability to boot the OS yourself and log in as the user (because again, you don't have the decryption key, you have the user's login credentials).

But that's the same thing that happens with full disk encryption. They come get physical access to the machine but don't have the decryption key yet so they compromise the unencrypted part of the machine which is what prompts you for it, have that capture the key when you enter it, and now they have the key when they come back to use it.

If anything allowing the short password is even worse, because if you leave your machine in suspend you expect it to prompt for your unlock password but not the full disk encryption key when you come back, so the latter would be suspicious but the former doesn't let them unlock the disk, and now you're using the short password for both.

> You are also presupposing what the TPM is bound to. I don't use Windows, but using systemd-cryptsetup I could configure a TPM to bind to the drives in the system; in this way, it will refuse to boot my legit OS while your malicious disk is installed (well, it will demand a recovery key). Again, setting off alarm bells, and if I discover the disk with my recorded credentials before you can physically access it, I can just destroy it.

Except that it doesn't need to be installed once you're at that point. By then it has already captured your credentials and stored them or sent them to the attacker over the network, so it can disable that device right before it goes to boot into the original operating system.

Also notice that the original premise was to make it easy for ordinary users and now the workaround is to install Linux and change a setting that will confuse people as soon as they leave their own USB stick plugged into their computer.

There is no password. The machine will fail to boot and decrypt you hard drive.

So don't turn off secure boot. Replace the target machine with an identical decoy machine set up to capture whatever credentials are required to log in to the machine once BitLocker auto-unlocks, then use these to log in to Windows on the original machine and steal any encrypted data accessible by the user who logs in.

This would be more difficult to pull off in the presence of non-password security like a hardware token, as you'd need to forward the actual login UI to the decoy machine, but still not terribly difficult if the login UI will display on an externally-connected monitor and accept input from an externally-connected keyboard and pointing device, and the hardware security device connects via an external interface like USB.

You're now just making up more and more ridiculous nonsense to beat a wrong point.

Either you're entering something into the machine to authenticate yourself or they can just copy or modify your files without authenticating to begin with.

If they just want your password they don't need to decrypt your hard drive, they can format it and install a rootkit that steals your password as soon as you try to login.

I—like most people—don't have a maid. Is Tom Cruise going to break into my house to add a keylogger to my computer without me noticing?

If your threat model includes evil maid attacks a TMP will not save you. They can just install a physical keylogger and then do whatever they want. The only threat model that a TPM helps with is where the owner of the computer is considered the threat by someone else.