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