Is usage of TPM recommended on Windows and Linux? Possible to enable at Win and disable at Linux at once?

Hello, i found some articles about tpm, but i found them confusing, they tell they have advantages and disadvantages so i still don’t know if i should use it.
I want to do dualboot, on one disk Windows and on other Linux (kicksecure).
Win ofc for public use, kicksecure for private sensitive use.
Question is should i use Windows with bitlocker and TPM or Veracrypt and no TPM, also Kicksecure with LUKS2 with no TPM or also find a way to implement it?
Is it possible to left TPM on Windows and disabled on other disk with LUKS2?

It depends on your threat model.

Simply put TPM is a storage space where the OS can save things like an SSD.
The core difference is that TPM has very very very limited space and is designed only for saving credentials.

If you save credentials like for LUKS-encryption in the TPM2.0 you need to trust the TPM chip to be secure enough for your use case. Here Threat-Model applies.

You can keep TPM2.0 active and enabled in the UEFI/BIOS it will not harm you.
However, I would generally argue you should not use TPM for FDE or any sort of encryption.

Interesting, what would you recommend for encryption instead of TPM or FDE then?

TPM is not FDE and FDE is not TPM. TPM is also not doing what FDE does vice versa.

FDE is the encryption itself. TPM is the where the key sits.
If you now have set it to a passphrase the decryption key is sitting in your head, while if you choose to use TPM for FDE, the decryption key for FDE is sitting inside the TPM chip instead of your head.

Would you say the same for Yubikey? I’ve always found hardware keys for decryption interesting, but no experience with it.

If you use FIDO2 for the encryption and do not keep the Yubikey constantly connected with your device (e.g. these small yubikeys like this one: USB-A YubiKey 5 Nano Two Factor Security Key | Yubico) than this becomes a whole other story.

It than would work completely different than with TPM2.0 and is also more secure. So yes this is definitly a better choice than TPM2.0.

TPM is pretty much required if you want FDE on an headless or remote system like a home server/router/firewall. There are other solutions, but they are more complex or necessitate extra hardware, whereas any modern motherboard has a TPM chip.

You seem to distrust TPM’s security - might elaborate why?

To give a counter example, IncusOS is a relatively new project, I recently encountered. It is praised to use

modern security features like UEFI Secure Boot and TPM to provide a safe boot experience and seamless full disk encryption.

Main design features:

  • Boot safety (UEFI Secure Boot and TPM 2.0 measurements)
  • Full disk encryption (TPM backed LUKS and ZFS encryption)

Source

I would see TPM for FDE with headless systems rather as convenience feature than necessity. Remote FDE unlock on Debian for example can be easily configured via pre-boot SSH/Dropbear initramfs. Install package, add a one-liner to 2-3 files, and you’re good to go.

I would see TPM for FDE with headless systems rather as convenience
feature than necessity. Remote FDE unlock on Debian for example can be
easily configured via pre-boot SSH/Dropbear initramfs.

I see a hands-off recovery after a power failure or unplanned reboot as a necessity more than a convenience. And this approach introduces its own security trade-offs like having to open the SSH port and storing the key in the clear in the initramfs.

Pre-boot SSH initramfs loads normally on every boot, power failure or reboot reason doesn’t really matter here. And only the public key part is stored as plaintext initramfs - secrets don’t leave your machine. Usage on home server - with physical access as fallback - hence should be perfectly fine.

Given external provider/VPS, it certainly depends on offered access methods and own goals. If one goal is confidentiality, we would rather need to talk about TEE than TPM for encrypted storage and zero trust model against provider. Using TPM without TEE alone, you would need trust the provider to not log/monitor your LUKS key stored in unencrypted RAM, which somehow foils the motivation to use FDE in the first place. Or you just care about physical theft protection.

But having reading OP’s post again, goals and threat model aren’t clear to me yet.