-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Making credentials using fido_dev_make_cred: only one algorithm at a time supported #140
Comments
Hi, With the current API, your only option is to iterate over the list of preferred algorithms. We will revisit this for libfido2 2.0. With some luck, there will be an API to retrieve the list of supported algorithms by then, and we will be able to keep the credential API simple as it is. -p. |
I tried to iterate (with uv=FIDO_OPT_FALSE and no pin) but with some authenticator other than YubiKeys (HyperFido, eWMB GoldenGate) user presence is always required. I added cbor_add_bool(item, "up", false) to cbor_encode_options in cbor.c to circumvent the problem. Can you add the option "up" to fido_cred_t (same as fido_assert_t) ? |
This sounds a bit strange. Are you excluding credentials, i.e. using fido_cred_exclude()? |
No. fido_cred_t* cred = fido_cred_new(); It works great with some authenticators (YubiKeys, SoloKeys, ...) but not all (HyperFido, eWMB GoldenGate). |
Could you send me the output of FIDO_DEBUG=1 with one of these authenticators (HyperFIDO, eWBM)? |
First detection en print info, then algorithm detection. is_fido: unsupported report len |
The detection iterates through { COSE_ES256, COSE_EDDSA, COSE_RS256, COSE_ECDH_ES256 } |
Thank you for the debug info and apologies for my earlier brevity; I was short of time. Let's first get some things out of the way. The list of steps a FIDO2 authenticator takes when issued with a fido_dev_make_cred() (authenticatorMakeCredential in CTAP2) is defined in https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#authenticatorMakeCredential. The first step is to check for excluded credentials. That's why I asked about fido_cred_exclude(). The next step is to check for supported algorithms. Note that fido_dev_cred_make_cred() options (rk, uv) are not involved up to this point. What this tells us is that, unless excluded credentials are present, the authenticator ir supposed to return immediately if it does not support the requested algorithm, regardless of options. That is the first oddity in the behaviour you are experiencing. The eighth step requires the authenticator to wait for user consent. Again, regardless of options. That is the second oddity in the behaviour you are experiencing. If you look at the table of options defined for authenticatorMakeCredential, you will see that only rk and uv are defined. That is the third oddity -- 'up' should not play a role in authenticatorMakeCredential. In fact, I am fairly sure that if you pass 'up' in a authenticatorMakeCredential to a Yubikey, the Yubikey will fail the request with FIDO_ERR_INVALID_OPTION. Looking at the debug output, assuming you did not interact with the authenticator at any point, and that the authenticator only supports COSE_ES256, the authenticator's behaviour seems correct to me: the fido_dev_make_cred() call with COSE_ES256 fails with FIDO_ERR_OPERATION_DENIED in the eighth step, and the requests with COSE_EDDSA and COSE_RS256 fail in the second step with FIDO_ERR_UNSUPPORTED_ALGORITHM as the algorithms are not supported. |
You're right, it's fast if I add cbor_add_bool(item, "up", FIDO_OPT_FALSE) to cbor_encode_options because it returns FIDO_ERR_INVALID_OPTION version strings: U2F_V2, FIDO_2_0, FIDO_2_1_PRE But it detects the right algorithms. From the output I sent before (ie without forcing up to false) I've marked where I had to wait for 10 seconds while the authenticator winks. version strings: U2F_V2, FIDO_2_0, FIDO_2_1_PRE For the moment, I am not going to detect the supported algorithms. COSE_RS256 is deprecated and COSE_EDDSA is supported by none of my test devices. Thank you for your time. |
I am encountering the original issue while attempting to implement a WebAuthN client using However, for compatibility reasons, I need to support the version of Does |
For completeness' sake: Ubuntu 20.04 LTS includes |
Hi @Treeston,
I'm afraid not; the raw CBOR is not kept after parsing. |
So there is no way to obtain supported-algorithm information in the version listed above, then? I'd be stuck with trial-and-error iteration -- which, as previously mentioned, has some pitfalls with some authenticator models? (Not intending to blame anyone, just trying to evaluate where I stand. Thanks for your response!) |
Correct. I should also note that the algorithms member of the authenticatorGetInfo response structure is a CTAP 2.1 addition. Older CTAP 2.0 authenticators return a structure without this data (and |
Making credentials using fido_dev_make_cred.
The fido_cred_set_type funcion allows only one algorithm to be set.
The standard for pubKeyCredParams https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#authenticatorMakeCredential allows multiple ones.
As we don't have an API to check if an authenticator supports a given algorithm, we are forced to set the algorithm to COSE_ES256
The text was updated successfully, but these errors were encountered: