upvote
If you’re at all serious about security and not user convenience, you deploy BitLocker with a PIN instead of TPM only. And then a whole class of vulnerabilities goes away.
reply
It's probably all security theater. There's only so much trust you can put into some shitty vendor's TPM implementation
reply
"Disk must be in expected hardware environment" versus "Same environment plus PIN" makes a huge difference if a thief simply steals a whole computer.
reply
Just a PIN? For most people that's a 4-digit number, which has a worst-case scenario of 10,000 attempts and a median of only a few hundred. Why not use a full 8-digit password?
reply
Because the TPM effectively rate limits brute forcing of the PIN to one attempt per ten minutes.

https://learn.microsoft.com/en-us/windows/security/hardware-...

> For systems with TPM 2.0, the TPM is configured by Windows to lock after 32 authorization failures and to forget one authorization failure every 10 minutes. This means that a user could quickly attempt to use a key with the wrong authorization value 32 times. For each of the 32 attempts, the TPM records if the authorization value was correct or not. This inadvertently causes the TPM to enter a locked state after 32 failed attempts.

> Attempts to use a key with an authorization value for the next 10 minutes wouldn't return success or failure. Instead, the response indicates that the TPM is locked. After 10 minutes, one authorization failure is forgotten and the number of authorization failures remembered by the TPM drops to 31. The TPM leaves the locked state and returns to normal operation. With the correct authorization value, keys could be used normally if no authorization failures occur during the next 10 minutes. If a period of 320 minutes elapses with no authorization failures, the TPM doesn't remember any authorization failures, and 32 failed attempts could occur again.

reply
If you're really serious, you use a strong password, not a PIN.
reply
If you are at all serious about security you don't consider Windows.

Depending on how serious you are you also don't consider MacOS.

And then you kinda have a couple of things to chose from but ultimately you need to build your own security depending on your attack/threat model

reply
And then depending on how "serious" you are you also don't consider Linux.

But also, threat models and the best way to mitigate them aren't really a linear scale of being <unserious> to <serious>, but a complex consideration of a particular situation.

reply
The issues you linked with BitLocker are obvious properties of BitLocker-with-SecureBoot-only architecture. If you configure Linux that way, you get similar issues (for example, it's pretty easy to mis-configure TPM sealed disk encryption on Linux to still allow a recovery shell, which will run with the disk unsealed).

BitLocker with a password (the equivalent of the LUKS configuration in question) does not share these issues.

reply
Bitlocker with a password has always felt like a second class citizen to me. You have to dig into a bunch of group policies to use it. Maybe most people don't even realize it exists.
reply
For the system drive they seem to really strongly prefer PIN, which also doesn't have the problems linked above. I was going to use PIN as my example but didn't want to explain another set of recent BitLocker conspiracy theories yet again; maybe I should have.

It is annoying that they hate password for system drive _so_ much; the reason is actually pretty obvious when you think about how their "happy path" AD-driven enterprise deployment with stupid password rotation requirements works (and FileVault is a nightmare in this scenario), but I wish they'd make it easier for individual power users.

reply
Yah, it seems blatantly hostile how much they hide it.

I can understand the default being TPM-only + online key backup, huge amounts of the population forget their login passwords (which can be involuntary, e.g. head injury) and huge amounts of them still want some backup way to access their data rather than losing it forever.

But for anyone who cares just a little more, or would prefer to lose data in those situations, it's such an abnormal and hidden path that it's clearly blocking tons of people from choosing it.

reply
veracrypt lost their drivers license so afaik you should avoid it since it cannot update its drivers any longer. didnt see any news about them reacquiring that license
reply
Assuming this is what you are referring to, it was resolved within a few days. The incident being resolved just didn't make headlines. https://sourceforge.net/p/veracrypt/discussion/general/threa...
reply