My google-foo failed me as most "how it works" sections related to fido are very... let's say... consumer-oriented.

So openssh supports U2F natively when using the appropriate elliptic-curve-based cipher (namely ed25519-sk and the NIST one, do mind the -sk: it makes the whole difference).

I could find no reference about how it actually works (I know there is a reference protocol documented by the fido alliance but it is certainly not browsable if you don't know where to look).

My very specific concern is that SSH keys can be created as non-resident. I.e. an handle is generated on disk but no copy is saved in the FIDO token (yubikey in this case to be specific). This means that ssh uses some kind of secret on the token (duh!) to transform that handle to an actual key. What I don't know is what secret is used for this. Is it using the Yubico OTP key in one of the slots or is it using something hardcoded in the key (or something else entirely)?

1 Answer 1


The documentation for the U2F-based formats are documented in the OpenSSH distribution in the file PROTOCOL.u2f. This outlines the formats, the design decisions, and all of the protocol messages.

As for whether the U2F device has the key resident or generated on the fly, that is specific to the key and the manufacturer. The way YubiKeys do it is outlined in their documentation:

When a user registers one of our U2F devices with a new service, the service provides an AppID (this is tied to the URL of the site and prevents phishing). The U2F device generates a random Nonce. We then take the AppID and the Nonce and run them through HMAC-SHA256 (a one-way keyed function), using a device-specific secret as the key. This device-specific key is generated on-chip at the time of manufacturing (just like the master key would be, if we were using regular key wrapping). The output of the hash function becomes the private key, and the Nonce value, together with a MAC (message authentication code), becomes our key handle. During authentication, the MAC helps to ensure that a key handle is only valid for the particular combination of device and AppID that it was created for during registration.

That documentation implies that the secret is different from the Yubico OTP algorithm, which uses a symmetric key (AES, I believe).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .