Or, alternatively, don't. Stuff in a TPM isn't for "security" in the abstract, it's fundamentally for authentication. Organizations want to know that the device used for connection is the one they expect to be connecting. It's an extra layer on top of "Organizations want to know the employee account associated with the connection".

"Your SSH keys" aren't really part of that threat model. "You" know the device you're connecting from (or to, though generally it's the client that's the mobile/untrusted thing). It's... yours. Or under your control.

All the stuff in the article about how the TPM contents can't be extracted is true, but missing the point. Yes, you need your own (outer) credentials to extract access to the (inner) credentials, which is no more or less true than just using your own credentials in the first place via something boring like a passphrase. It's an extra layer of indirection without value if all the hardware is yours.

TPMs and secure enclaves only matter when there's a third party watching[1] who needs to know the transaction is legitimate.

[1] An employer, a bank, a cloud service provider, a mobile platform vendor, etc... This stuff has value! But not to you.

▲

tiberious726 19 hours ago | parent | next [-]

> TPM isn't for "security" in the abstract, it's fundamentally for authentication

What on earth do you think I make my users present keys for???

You know all those guides saying "you should never copy an ssh private key over the network. Make a new one for each device" that every idiot dev ignored? Now I can enforce that.

	▲	doubled112 18 hours ago \| parent [-]
		Yes, this would stop people from asking for my key when they choose the wrong one for a new AWS EC2 instance. Not a chance. It is my key.

▲

Liskni_si a day ago | parent | prev | next [-]

TPMs can be useful to you as an individual if you're trying to protect against an evil maid attack. Although I think Linux isn't quite there yet with its support for it. The systemd folks are making progress though.

▲

SAI_Peregrinus 21 hours ago | parent | next [-]

That only helps if you set a strong password as your TPM PIN. Otherwise its hardware-bound with no access control, and just as susceptible to evil maid attacks as storing the keys directly in a file.

▲

ajross 20 hours ago | parent | prev [-]

> evil maid attack

So does a pass phrase though, with significant less complexity and fragility.

Again, the linked article and responses here are making IMHO a pretty bad mistake with threat model analysis.

▲

Liskni_si 20 hours ago | parent [-]

I don't see how entering a passphrase into a compromised boot loader/kernel/initramfs is as safe as a measured boot with TPM providing the decryption key only if nothing seems to have been tampered with. Can you elaborate please?

▲

ajross 20 hours ago | parent [-]

I said this elsewhere in the thread, but to repeat here:

Can you explain why securing the ssh keys on a host that was fully compromised like that is anything but theater? Fine, you can't get the key out. You can just run the command directly.

Again, there are use cases where TPMs provide value to authenticate specific devices. But they are not and never have been about "keeping secrets". Your secrets are trash once the device is compromised.

	▲	Liskni_si 20 hours ago \| parent [-]
		Well I wasn't talking about ssh keys at all - that's where the misunderstanding comes from. I was simply trying to counter your claim that TPMs are never ever useful for individuals. They can be useful to individuals worried about having their boot tampered with. I absolutely agree that they do zilch to protect your SSH keys. Hardware security keys that need physical confirmation of presence are much better for that use-case.

▲

red_admiral a day ago | parent | prev [-]

> TPM isn't for "security" in the abstract, it's fundamentally for authentication.

Which is what SSH keys are for?

The advantage of this approach is that malware can't just send off your private key file to its servers.

▲

ajross 20 hours ago | parent [-]

> The advantage of this approach is that malware can't just send off your private key file to its servers.

The use case is ssh keys! If malware can run an ssh command on the remote host, it doesn't need to steal your key, it can just install itself there. Or add its own keys to the access, etc... At best, you'd have to detect and fix that sort of thing with auditing and control, something that's isomorphic to the "third party" requirements I was mentioning.

To repeat the third time: this is all terrible threat model analysis. TPMs do not have value for individuals managing access between trusted devices. TPMs are for third-party validation.

▲

palata 16 hours ago | parent [-]

> TPMs do not have value for individuals managing access between trusted devices.

But you just admitted that it prevents the key from being stolen, right? So the value is that the key cannot be stolen. Doesn't mean that a malware cannot use it of course. Just that it cannot extract it. Which is better than a malware extracting it.

	▲	16 hours ago \| parent [-]
		[deleted]