a meaningful subject line
a meaningful subject line
Posted Aug 13, 2025 19:21 UTC (Wed) by mirabilos (subscriber, #84359)Parent article: Don't fear the TPM
But why would I want to do that? I want to back up these things to my normal backup storage.
> its use demonstrates that a user has access to a specific piece of hardware
But what’s the use? Hardware goes kaputt. I can quickly obtain a replacement, restore onto it and things work as before, if I don’t use the TPM for/like that.
Also, the RNG on TPMs is notoriously bad; the baseline for such an RNG is incredibly low (PRNG with “unknown and not exfiltratable seed” suffices), there’s no guarantee for entropy. (Full disclosure: I have written software to use a TPM 1.2, to read from its RNG and put this as *additional* source into the kernel entropy pool. Never as single source.) This is another good reason why a TPM should never be used to generate any cryptographic key, its random bits are not much better than those of plastic router boxen. Always let the OS do it — and not just Linux /dev/urandom with its crippled pool size either. touch ~/.rnd and then put 「openssl rand -rand ~/.rnd -writerand ~/.rnd 4 >/dev/urandom」 into your crontab, run it at least hourly. Over time, enough entropy will amass in ~/.rnd (each call also reads from the kernel and mixes that into the seed file), and a few bits will also find their way back to the kernel each call, which is not a bad thing either.
> 2048-bit RSA keys
Right. It’s called baseline for a reason…
> AMD's integral TPM has some problems with the random-number generator
*cough*
> everyone builds their own initrd
Better that way. I can include things to set up the network so I can unlock LUKS via SSH ;-)
But good to know that dracut is not something one wants to play with, I’ll stick to initramfs-tools as well then.
(OT: the plain text format doesn’t do quotes well, apparently ☹)
Posted Aug 15, 2025 11:06 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
But what’s the use? Hardware goes kaputt. I can quickly obtain a replacement, restore onto it and things work as before, if I don’t use the TPM for/like that.
The use case is hardware that can be tampered with by an attacker in some way; if the attacker images your disk, then the TPM-backed secret doesn't let them decrypt it, and they've gained nothing. If you've set up a measured boot system, with the TPM only releasing symmetric keys when the measurements are correct, then the attacker also can't tamper with your system to exfiltrate data without you losing the ability to use that hardware for the intended purpose.
And you can still replace the hardware in this situation - it's just that instead of being able to take a HDD/SSD out of a failed machine and plug it into a new machine, you have to create new secrets on a new machine and restore from a securely kept backup. All you're doing is stopping an attacker from being able to do the same if they can borrow your laptop while you're (e.g.) drinking coffee with friends.
Underlying this is that it's only useful in cases where you need a guarantee that the user has access to a machine which has not been tampered with since you last verified its trustworthiness via physical access; my work laptop has FDE keys in the TPM so that I can boot without network available, but I need an alternative keying method (e.g. access to a secured physical network, a FIDO U2F device, a long passphrase) to get in if my device appears to have been tampered with (even if I did the tampering). My home server, however, is physically secure, and does not use a TPM to boot.
Posted Aug 15, 2025 18:40 UTC (Fri)
by raven667 (subscriber, #5198)
[Link]
> But why would I want to do that? I want to back up these things to my normal backup storage.
> its use demonstrates that a user has access to a specific piece of hardware
> But what’s the use? Hardware goes kaputt. I can quickly obtain a replacement, restore onto it and things work as before, if I don’t use the TPM for/like that.
Not everyone has the same security requirements, for a fancier HSM the answer to backup/restore is cutting the key into chunks and storing parts of the key on smartcards that are distributed to multiple people requiring some number of them to come together to combine their key parts into a whole signing key. For more everyday situations with something like a Yubikey the answer can be buying two of them, and enrolling both everywhere you need it, then storing one safely as a backup. For something protected by a TPM like on-disk encryption you can use normal backup methods for the data while the system is unlocked and accessible, with whatever encryption policy for the backup you want separate from the host full-disk-encryption, knowing that if the hardware breaks, or the key is intentionally destroyed, the data is inaccessible even if the disk/nvme itself is "fine". I'm would guess for things like TPM you don't have to create the key on the TPM, I think you can create a private key on the host and push it into the device one-time as a write-only operation, similar to how a Yubikey can store some number of TOTP/HOTP tokens. I thought Passkeys worked the same way but it seems that there are mechanisms to sync the actual private keys between devices, or transfer them during device upgrades, rather than enrolling each device under your control with a separate hardware-locked key into each service doing key-based auth. The security properties of a key embedded in a physical object are easier to reason about though, no amount of OS-level RCE bug can remotely access a key sitting on my desk, it would take literal ninjas coming through my walls which is a whole different thing.
Use case for TPM-tied credentials
> its use demonstrates that a user has access to a specific piece of hardware
a meaningful subject line