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.
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.
What am I missing?
Thank you for your reply.
(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.)
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.
It does mean that they can't use the key a thousand times. But once? Yeah sure.
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`
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
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.