Put your SSH keys in your TPM chip (opens in new tab)

The general consensus has been that you create a key pair per client computer that you use. If one is stolen (say your laptop), you login from your desktop and revoke the stolen key. If the hard drive fails, you login from another client.

I don’t see much difference between that and storing the key on a TPM. If you have one key and you lose access to that key, then you lose access to the server.

Point: you need a backup key anyway.

It's unlikely to be inside the TPM. The way pretty much all TPMs store data is to use a key inside the TPM to encrypt data stored outside the TPM, because the TPM is a repurposed smart card with barely any storage or capabilities outside of DRM. Bitlocker is an extreme example of this, but things like Fapi_CreateSeal()/Fapi_Unseal() also store the sealed item outside the TPM even though they appear to be using the TPM for storage. So what you do is the same as what Bitlocker does, use the TPM's storage root key (SRK) to seal some master key (in Bitlocker terms the VMK) and the master key seals the encryption key used, which is also sealed with some user-entered emergency-access password or whatever that still gives you access if the TPM dies.

OTOH for SSH use if you lose the key you just create a new one, it's not like you've lost the only copy of your Bitlocker key.

Agree. This is why I do not use Passkeys, and I have 4 physical Yubikeys tied to every system I secure with them.

I have the same concern with all hardware used for storing keys and secrets for crytpo.

I mwan a key isn't that long. Convert it to a QR code, print it out and stick it somewhere safe.

The idea with HSM-backed keys is that even in case of compromise, you can clean up without having to rotate the keys. It also makes auditing easier as you can ensure that if your machine was powered down or offline then you are guaranteed the keys weren't used during that timeframe.

Without presence test (e.g. yubikeys touch) it's certainly not perfect. But it does close some real world attacks. Like the key can only be used while your laptop is on. (assuming laptop, here).

And keys cannot be stolen from backups.

Or stolen without your knowledge when you left your laptop unguarded for 5min.

Not every attacker has persistent undetected access. If the key can be copied then there's no opportunity for the original machine's tripwires to be triggered by its use. Every second malware runs is a risk of it being detected. Not so, or not in the same way, with a copied key.

That's still an improvement. In sophisticated attacks, attackers might well store stolen credentials and use them at a later, more opportune time.

Of course a real secure attention sequence would be preferable, such as e.g. requiring a Touch ID press on macOS for keys stored in the Secure Enclave. Not sure if TPM supports something similar when a fingerprint sensor is present?

TPMs support setting a PIN without which a key cannot be used.

The PIN can be an arbitrary string (password).

The promise of HSM, TPM and smart cards are that you have a tiny computer (microcontroller) where the code is easier to audit. Ideally a sealed key never leaves your MCU. The cryptographic primitives, secret keys and operations are performed in this mini-computer.

Further promises are RTC that can prevent bruteforce (forced wait after wrong password entry) or locking itself after too many wrong attempts.

A good MCU receives the challenge and only replies with the signature, if the password was correct. You can argue that a phone with a Titan security chip is a type of TPM too. In the end it doesn't matter. I chose the solution that works best for me, where I can either only have all keys in my smart card or an offline paper wallet too in a fireproof safe. The choice is the user's.

> my authenticator app on my phone

Depending on which authenticator app (or maybe applies to all?), that data either is, or can be, backed up.

A yubikey cannot be cloned.[1]

> the malware rides along this expectation and gets ahold of your private SSH keys and stores them or sends them off somewhere.

Ah, this is where your misunderstanding lies. No, the crypto operation runs ON the TPM or yubikey. The actual secret key NEVER lives in RAM. (ehem, after it was imported, if importing is the method by which it was generated)

[1] You know what I mean. Of course in principle it can be. But not like a phone where it can literally be sent via scp.

They can use the key as long as they can access your computer, but they shouldn't be able to get the secret key out of the TPM or Yubikey and use it elsewhere while your computer is off. That's the main point of HSMs.

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

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.

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

In some cases there is a work-around for bearer tokens. If they allow key/cert login to generate the token (either directly, or via oath), and the token can be generated with a short lifetime, you can build something pretty safe (certainly safer then having a not-expiring, or long TTL token in a wallet).

apologies for asking this question here instead of actually doing the research, but it always seemed to be that while putting keys in a secure environment would help against leakage of the private bits, there really isn't a great story around making sure than only authorized requests can be signed. is this a stupid concern?

It's also a bit outdated. OpenSSH supports FIDO2 natively, so all this gnupg stuff is unnecessary for ssh. One can even use yubikey-backed ssh keys for commit signing.

And the best thing is that you can create several different ssh keys this way, each with a different password, if that's something you prefer. Then you need to type the password _and_ touch the yubikey.

I'd say this is more up to date:

https://www.stavros.io/posts/u2f-fido2-with-ssh/

We've got private Git repos only accessible through ssh (and the users' shell is set to git-shell) and it's SSH only through Yubikey. The challenge to auth happens inside the Yubikey and the secret never leaves the Yubikey.

This doesn't solve all the worlds' problem (like hunger and war) but at least people are definitely NOT committing to the repo without physically having access to the Yubikey and pushing on it (now ofc a dev's computer may be compromised and he may confirm auth on his Yubikey and push things he didn't meant to but that's a far cry from "we stole your private SSH key after you entered your passphrase a friday evening and are now pushing stuff in your name to 100 repos of yours during the week-end").

Only if you do something like this... export HISTCONTROL=ignorespace

Personally I like this which reduces noise in history from duplicate lines too. export HISTCONTROL=ignoreboth:erasedups

If you run into the link to this, is love to read it. Proper, modern, pcrphase binding with a signing key should remove these firmware update issues irt the raw pcr value changing

Lots of ways to establish a persistent presence with a short time life key, especially if it is in env or a file it is trivial to find.

In theory the Linux kernel keyring would help here, even with a tsm or in conjunction with it.

Unfortunately as the industry abandoned the core Unix permission system (uid/gid) all of these methods just get a devfs[null] bind mount.

Only process that also support the traditional co-hosting model like nginx and Postgres do.

We would need nonce keys to gain no value from kernel memory or hardware storage.

The integration of the ed25519-sk keys is just so easy and similar to normal ssh keys, so the upgrade is way easier.

You just need to tighten your sshd config, you can even add a "touch required" of the Yubikey to the sshd config. Has been in debian stable since like 11 I think?

So it's super friendly to integrate and very secure, as you need to physically be on your pc, have your yubikey and have your exact pc. So that's a lot of factors.

Not sure I get that. If you generate it "in the cloud", doesn't it mean that someone else (the cloud) has access to it?

But then why not use the Yubikey directly?

Do you have any more info you could add about that topic, or a direction to point me? As far as I know, (systemd-)pcrphase is for measured boot, but I'm not sure how that interacts with signing keys.

As someone who stores my SSH keys in my TPM, and has struggled with picking the right PCR values for Secure Boot in the past, I'm interested in learning more.

Anything pkcs#11 you can proxy. I'm using that on some systems - I have an old notebook with a nitrokey hsm at home. It binds pkcs11-proxy to a local wireguard interface, so I'm registering systems I want to be able to use those keys to that notebooks wireguard. They still need a pin for unlocking a session as well.

Where "everyday" means security from what kind of attacker?