Hacker News Reader

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.

And (unlike on your computer or phone), the HSM/TPM has its own CPU/memory and firmware, it's in control from the start of boot.

For SSH to use your keys a calculation has to be done using your private key and then send the results back to the remote site so it can validate that you got the results that prove you have your private key. The TPM and your yubikey do not do this calculation. They allow software on your computer to access the private key in plaintext form, perform this calculation, and then send the result (and then presumably overwrite the plaintext key in RAM). If your system has been compromised, then when this private key is provided to the host based software, it can be taken.

It is not present in the RAM with smart cards, and especially never with server type HSM:

https://wiki.archlinux.org/title/SSH_keys#Storing_SSH_keys_o...

And even the password can be forced to be re-entered by the agent for every use, if that level of security is wanted.

Yubikey (and nitrokey and other HSMs) are technically smart cards, which perform crypto operations on the card. This can be an issue when doing lots of operations, as the interface is quite slow.

Downvoted - this is false, sorry. The whole point of security keys (whether exposed via PKCS#11, or FIDO) is that the private key material never leaves the security key and instead the cryptographic operations are delegated to the key, just like a commercial HSM.

Technically, a private key that was imported (and is marked as exportable) to a PKCS#11 device can subsequently be re-exported (but even then, during normal operation the device itself handles the crypto), but a key generated on-device and marked as non-exportable guarantees the private key never leaves the physical device.

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

Also a Yubikey requires you to physically push it to sign. So an attacker needs to have physical access.

Yeah but they already mentioned that they expect the attacker to hijack your ssh command so you'll touch it yourself, thinking you're authorizing something else than you actually are.

It does mean that they can't use the key a thousand times. But once? Yeah sure.

> hijack your ssh command so you'll touch it yourself, thinking you're authorizing something else than you actually are.

That doesn’t do anything at all.

1. If the attacker is redirecting you to a different host then ssh will simply refuse to connect due to known_hosts (I guess they could have added to that file too, redirect you to a honeypot and then hopefully you’ll run “sudo” before realizing but then at that point just hijack “sudo” itself in the local machine)

2. If the attacker is trying to let you connect and eavesdrop your connection to still credentials then that also still doesn’t work as the handshake for ssh is not vulnerable to replay attacks

The attacker could trick you into signing something I guess but then that still doesn’t do anything because secrets are not divulged at any point

I guess if the yubikey is also used for `sudo` then your attack makes more sense, as the attacker could prompt you to authenticate a sudo request when you call the evil `ssh`

Okay let me elaborate how I envision that attack to work:

1. attacker wants to use your yubikey-backed ssh key, let's say for running ssh-copy-id once with their own key so they can gain access to your server

2. thus they need to trick you into touching the key when they run that command

3. the best way to trick you is to wait until you do something where you'd normally need to touch that key yourself

4. so they alias ssh to a script that detects when you're trying to connect to this server yourself, and invoke ssh-copy-id instead, which prompts you to touch the yubikey and you do

5. spit out a reasonable looking error (something that makes you think "bloody DNS, it's always DNS, innit" or something silly like that); then they undo the alias so you succeed on the next try and suspect nothing

That's a valid attack, but one thing is that they only get access this one time, and you may realise that something wrong happened (maybe not).

But they won't get your private key.

> But they won't get your private key.

Indeed, that was my point exactly a couple posts up the thread. :-)

> you may realise that something wrong happened

I think I can iterate on the exact mechanics to make this less likely. I mean it's getting off-topic but the one thing that comes to mind is to enable ControlMaster for all ssh connections which allows any second ssh invocation to skip the auth and just re-use the existing connection. ssh-copy-id is near instant then and doesn't ask anything.

At that point you might—rightly so—argue that they're no longer tricking the user into authorising a different operation. Just a reminder that if someone can run code as your local user, they can easily and sneakily gain access elsewhere. Even if you need a yubikey touch to connect there.

The original attack idea of timing the yubikey touch for when you normally expect to touch it might still be relevant for a scenario like ssh-agent forwarding to a malicious box. They can't run code as your local user, but can still perhaps trigger the agent to interact with the yubikey. Maybe.

I know the title says "in your TPM chip" but the method described does not store your private key in the TPM, it stores it in a PKCS keystore which is encrypted by a key in your TPM. In actual use the plaintext of your private ssh key still shows up in your ssh client for validation to the remote host.

The recommended usage of a yubikey for ssh does something similar as otherwise your key consumes one of the limited number of slots on the key.

I really don't think this is true for FIDO2 like Yubikey. My understanding is that your ssh client gets a challenge from the server, reads the key "handle" from the private key file, and sends both to Yubikey. The device then combines its master key with the handle to get the actual private key, signs the challenge, and gives the result back to your ssh client. At no point does the private key leave the Yubikey.

What am I missing?

I don't know if you are missing anything. That's why I'm asking and making statements about how I understand the various processes to work. I want to understand how it is that the only device that interacts with the yubikey/tpm, when compromised, can't be subverted to the attackers ends.

Thank you for your reply.

Perhaps one extra bit to add: you've mentioned consuming slots on the device - that's what happens if you generate a resident key. Those keys live on the device and can be used from any computer you plug them into, without having to retain/copy any files. A non-resident key, on the other hand, is derived from the master key on the device, and a "handle" that's stored as a file on your computer. You can have as many as you want, but if you lose either the file or the hardware device, they're gone.

(Others in the thread have confirmed that both resident and non-resident keys never leave the hardware. If you generate one that requires touch, they're fairly secure - you need physical presence and confirmation for every operation.)

I don't think this is right.

Yes, with TPM and yubikey you have the option to store the per key material on disk, encrypted by the TPM. But the way this is then used is that the PKCS software sends that encrypted blob AND the requested operation, and gets only the output back. The CPU doesn't get the SSH private key back. Just the output of the RSA operation using the key.

This article's method is bad, basically the same as systemd-creds (not itself bad, just extremely compatible), take a look at tpm-ssh-agent or gnupg for how to do that part the right way (the party they don't do right is bind/sign to pcrs, which is just low hanging fruit in today's day and age...)