upvote
> No, the KEK is stored inside the TPM

No. Technically, TPMs can store secrets (limited due to little nvram), but no FDE implementation as far as I'm aware does this. TPMs wrap/encrypt the key and return an encrypted blob which will be stored in the header which will be decrypted upon request. The actual KEK is never stored on the TPM.

> I don't think Bitlocker does that

It does, which is why cryptsetup was much more affected by the faulTPM exploit: https://arxiv.org/abs/2304.14717

> 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.

Not only do they do the same thing, they often use the same cheap chips. I don't see the benefit in using a separate device when you can have one SoC because there are too many downsides. Not only are dedicated devices vulnerable to sniffing and fault injection attacks, the extraction of secrets is actually feasible with the right kind of equipment. SoC solutions make this impossible (manufacturing levels are simply too small). Apple, Google, and Intel (Panther Lake) have solved this the right way. Open Source security can and should be shifted to PIN dependent key enrollment to protect against backdoored or flawed secure elements.

reply
https://blog.scrt.ch/2024/10/28/privilege-escalation-through...

https://post-cyberlabs.github.io/Offensive-security-publicat...

Yes, the PIN is entangled with the key material. The admin PIN recovery techniques all involve enrolling additional unlocking methods.

Besides this, I completely agree with this post, especially:

> 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.

I've always found it silly that Microsoft's default BitLocker implementation doesn't make it easy to do the obvious thing that FileVault does and use the user's password as an additional wrapper to encrypt the KEK. Yes, then there's trouble when the user forgets their password and password-change rotation is a little annoying, but if you're in an enterprise scenario you need backup keys anyway, and your users are still as likely to get BitLocker'd by PCRs changing (ie due to EFI updates) than forgetting a password anyway.

reply