Comment by Borealid

> That's not how it works. The KEK is not stored inside the TPM, but encrypted/decrypted by the TPM.

No, the KEK is stored inside the TPM, and the DEK is decrypted by it. If you have three layers (two KEKs, one encrypted with the other) then sure. But at the end of the day one private key is actually stored inside the TPM, taking up as much space as the length of the key.

To be specific, Bitlocker uses a stored key, not a derived key.

> Bitlocker does that. Cryptenroll doesn't (https://github.com/systemd/systemd/pull/27502), which is bad but has not been fixed.

I don't think Bitlocker does that, because it's possible to set up admin PIN recovery techniques. That would be impossible if the PIN were part of the KEK.

> - The KEK should also depend on the PIN. Cryptpentroll does not do this at all and Bitlocker limits the PIN to 20 characters.

I agree.

> There are various manufacturers of TPMs and all of them have different implementations. Some of them had been broken in the past, which is why it's important to make secrets PIN-dependent.

I agree. Perhaps consider using a FIDO2 token (supported by cryptsetup) instead of a TPM. There are open-source implementations of FIDO2 and open-hardware ones too. There are even open-source implementations of FIDO2 where the key is in fact derived from the user's PIN (plus a stored secret). If you did that, you get the proper security properties even without cryptsetup mixing the two methods.

> I seriously doubt the author found a way to bypass PIN protected setups in general.

I agree - I think the author probably just found a flaw in the windows recovery environment and is talking up how a PIN only helps you if the attacker does not know your PIN (in other words, acting as if the PIN provides no threat resistance when really it provides an additional layer).

> As of this moment, I would rather look at it as a convenience feature. A high entropy password + a proper KDF (not possible on Windows) like scrypt or argon2 is the better choice. Encryption should be handled by SoC engines like on Macs, iPhones or some Android phones to mitigate other attacks and preserve performance anyway. Panther Lake CPUs with vPro support do on Windows.

I think the best you can do right now is to layer a password with a hardware device. I don't think saying that the hardware devices are flawed means they are not useful as PART OF the security setup. It would certainly be nice if the software did this automatically/easily and it's unclear to me why it does not.