* The way that e.g. macOS FileVault works, where you enter your password in EFI, before the machine boots and before the OS is loaded.
* The way that e.g. iOS works, where there is an unencrypted partition containing the OS (mounted read-only), and an encrypted partition containing the data. The OS boots off the unencrypted partition, then you have to enter your password to unlock the data partition.
* The mode you're describing, where the unlocking happens automatically if and only if nothing has been tampered with (the encrypted hard drive hasn't been swapped into another machine, etc). With this mode you're relying on the fact that when the OS boots it won't let you do anything without entering a password, even though the disk is already unlocked. Assuming there are no bugs in the login screen, no way to physically read the contents of RAM (where the encryption keys are), and no way to access the contents of the TPM, this approach is just as secure.
That's a lot of assumptions. Or, as Jayne Cobb might say, "I'm smelling a lot of 'if' coming off this plan."
Those assumptions that you criticize hold true for the realistic threat faced by the vast vast majority of people: opportunistic taking of personal data by device thieves, intruders, and others with physical access to the machine. If you are worried about more sophisticated attacks, then you can easily ratchet up BitLocker's security by requiring a boot-time PIN, dongle, or password in addition to the TPM/SecureBoot measurements. You will also want to be more selective about the hardware that you use.
On a CoreStorage Filevault 2 system, the Recovery HD is used as the boot loader, calling an EFI program named "boot.efi" present on the filesystem.
On a APFS system things are a bit different; the Recovery HD is still used, however this is now a Logical volume presented from the main volume group, with the update to High Sierra a Firmware upgrade was pushed out to all supported systems enabling the EFI to grok APFS.
Edit removed terminal output
I used to work on BitLocker so I'm biased, but it's not pointless at all. If the hardware configuration, firmware, bootloader, boot settings, etc. are unchanged, as measured by Secure Boot and then each subsequent boot component, the TPM releases the key and automatically unlocks the drive. From that point forward, security depends on OS-level authentication and authorization. Even assuming poor hardware-level security, this will still protect against the only reasonable threat faced by most people: access to private data by device thieves or physical intruders.
If you are in the tiny minority that actually wants to protect yourself against sophisticated actors who have exploits for the OS-level security, or the ability to extract keys from a running system or with a cold boot attack, you will want to be selective about your hardware and you might want to additionally rely on a PIN, password, or dongle in conjunction with the TPM/SecureBoot protection.
That meant that if you wanted to travel you had to have the printed key with you, or at such reboots at least phone somebody to who you have given that key. Which isn't a problem in an organization, were that somebody are the admins, who were those who made the keys before they gave you the notebook.
I don't know how it works currently, if MS invented something more convenient recently.
But you still have to type it in.
I do this regularly as a recent W10 upgrade broke the SoftTPM in my Ryzen CPU (no longer recognised at boot), so I type it in everytime I boot windows (so once or three times a month).
It's very resilient since it has a built-in Error Detection Code for each 6 digit pair entered, if you make a typo, it likely will immediately complain and prevents entering any more of the code.
For the few times in the month where I need Windows, it's not worth the effort.
From my previous experience, Windows will happily insert the decryption key into the TPM once you enter the recovery code.
Things are different in the case of something like a phone. In that case you are pretty much forced to use some low entropy key that could otherwise be brute forced. Then a secure hardware device makes sense, particularly if the phone does not use the device for everything but the kitchen sink as in this case.
A nice improvement would be to use a PIN entered at boot for purposes of drive decryption and then automatically pass it through to the OS-level login.
Well, to whom do I tell my long passphrase? Right: my computer. Every morning. Is it running the same software as last night, no keyloggers, etc?
That’s what the TPM is for.
Last I knew, Windows does not like to let you enable this mode in a machine with removable RAM that don't have compensating security features.
Windows 100% allows you to use TPM + bitlocker and secure the keys on AD on any sort of computer, regardless of removable ram or not.
It is kind of useless as it’s practically impossible to keep secrets from a local attacker on the Intel platform, but against an attacker that’s not very determined it helps. At least you can’t just boot a Linux cd or put the disk in another machine to get the data.
I had to go look this up. Apparently there is mode of full disk encryption that automatically decrypts the disk every time you boot up if some stuff has not been modified. That strikes me as quite pointless.
* https://en.wikipedia.org/wiki/BitLocker#Encryption_modes