Hacker News new | ask | show | jobs
by cflee 2818 days ago
Technical Manual at https://support.yubico.com/support/solutions/articles/150000...:

> Like FIDO U2F, the FIDO2 standard offers the same high level of security, as it is based on public key cryptography. In addition to providing unphishable two-factor authentication, the FIDO2 application on the YubiKey allows for the storage of resident credentials. As the resident credentials can store the username and other data, this allows for truly passwordless authentication. YubiKey 5 Series devices can hold up to 25 resident keys. If RSA keys are used, there is a maximum of three RSA with the rest being ECC.

I wonder what the user experience will be like at 25 resident keys, they mention that the YubiKey Manager (ykman) can set/change FIDO2 PIN and reset FIDO entirely, but nothing about managing individual resident keys/credentials.

It seems like it might be a bit challenging to manage this, especially if end-users accidentally register the authenticator multiple times or run out of the 25 slots for some other reason, and be told that they need to reset the whole authenticator and do recovery for all their sites...

1 comments

My understanding is that for udf / fido2 authentication, keys are not stored but rather regenerated with an HMAC

https://developers.yubico.com/U2F/Protocol_details/Key_gener...

I'm curious what these resident keys are for.

> keys are not stored but rather regenerated with an HMAC

That's an implementation detail to support an unlimited number of registrations. FIDO doesn't require derivation this way. Keys can be stored if desired. IMHO it would be superior, given that the device/protocol is designed as a first-class web-aware protocol, not a generic abstraction divorced from the reality of the primary use case. So, given that you are going to use the device with a web browser, the browser should assist you in storing the keys in the cloud. (NB: doesn't have to be and shouldn't be the raw key, it can be sealed by the device or even device/browser combination). This way you have a central location to find all of your registrations and can selectively revoke them easily.

Anyway ...

> I'm curious what these resident keys are for.

It was stated in the parent you are replying to:

>> As the resident credentials can store the username and other data

They continue doing the key wrapping with HMAC for U2F. Resident keys are for the "passwordless" authentication method under FIDO2.

U2F requires that the server must know exactly which keyHandles to request, based on the username (and probably password) that is supplied earlier by the user, so that the token can take the keyHandle and derive the key.

In FIDO2 "passwordless" mode, there's no username or other identifier presented, so it's just a generic request for credential from the server -- the authenticator has to independently figure out which key to present based only on the origin/domain, and maybe even present a list of stored keys (probably effectively a list of accounts?) to the user for selection. So it'd need some local/resident storage of various bits like the origin, maybe a user-chosen account name, and the actual credential, since it can no longer rely on the server to do store all these bits.

The spec doesn't insist on it, but that's how Yubico devices do it, yes. It's the straightforward thing to do when your scheme eventually relies on ECDH and there's an obvious and performant way to go from a base secret to a specific-use secret (via a KDF, here HMAC) to a public key (via scalarmult). It'd be less straightforward if your key generation is expensive and complicated.
If I'm understand correctly, the resident keys can be used in the case of a non-ECDH scheme and otherwise they wouldn't be used? How flexible is the FIDO2 specification on crypto schemes?
I don't understand what you're saying. Which resident keys?

WebAuthn adds a number of crypto schemes -- to wit, I think they add RSA. You can certainly deterministically generate RSA keys but it's a lot more of a pain in the neck than x = HMAC(k, "u2f" + custom); P = xG :)

In the parent comment link to the technical manual it mentions 25 resident keys can be stored.

It is now starting to make sense to me why. As jiveturkey pointed out, it allows usernames to be stored. And, as you're pointing out, it's useful for RSA or maybe other crypto. Thanks.