Hacker News Reader

Comment by wang_li | Hacker News Reader

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.

View on HN

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.

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

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

Reply on news.ycombinator.com