7 ms·

I had a friend tell me once that his yubikey is more secure than my authenticator app on my phone because my phone has this giant attack surface that his yubike

by wang_li 6mo ago

I had a friend tell me once that his yubikey is more secure than my authenticator app on my phone because my phone has this giant attack surface that his yubikey doesn't. Yet the yubikey has an entire attack surface of the computer it is plugged into. Which is largely the same or worse than my phone's. I'm wondering why that doesn't apply here. The TPM holds the key to the cipher that is protecting your private keys. Someone uses some kind of RCE or LPE to get privileged access to your system. Now it sits and waits for you to do something that requires access to your SSH keys. When you do that you are expecting whatever user prompts come up, the malware rides along this expectation and gets ahold of your private SSH keys and stores them or sends them off somewhere. I'm not even positive that they need high degree of privileges on your box, if they can manipulate your invocation of the ssh client, by modifying your PATH or adding an ssh wrapper to something already in your path, then this pattern will also work. What am I gaining from using this method that I don't get from using a password on my ssh private key?

systd-basiliskd 6mo ago
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.
- lokar 6mo ago
  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.
- wang_li 6mo ago
  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.
  - systd-basiliskd 6mo ago
    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_on_hardware_tokens 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.
  - finaard 6mo ago
    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.
  - Nextgrid 6mo ago
    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.
Liskni_si 6mo ago
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.
- hart_russell 6mo ago
  Also a Yubikey requires you to physically push it to sign. So an attacker needs to have physical access.
  - Liskni_si 6mo ago
    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.
    - akdev1l 6mo ago
      > 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`
      - Liskni_si 6mo ago
        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
knorker 6mo ago
> 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.

by wang_li 6mo ago

systd-basiliskd 6mo ago

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.

lokar 6mo ago
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.
wang_li 6mo ago
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.
- systd-basiliskd 6mo ago
  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_on_hardware_tokens 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.
- finaard 6mo ago
  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.
- Nextgrid 6mo ago
  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.

Liskni_si 6mo ago

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.

hart_russell 6mo ago
Also a Yubikey requires you to physically push it to sign. So an attacker needs to have physical access.
- Liskni_si 6mo ago
  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.
  - akdev1l 6mo ago
    > 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`
    - Liskni_si 6mo ago
      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

knorker 6mo ago

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