Google account authentication through FIDO2

[Xavier CHAPRON]

Hello,

As a quick introduction, My name is Xavier Chapron, I work at Ledger and I am one of the developer working on the support of FIDO2 protocol on Ledger devices.
FIDO2 ledger application code is available here: https://github.com/LedgerHQ/app-security-key/

I am having a difficult time understanding why I can't use this application as a 2FA on a Google account.
I am quite sure it was working sometimes ago (~20 April 2023), but now all I get is errors that are not really understandable.
Note that the same setup correctly works on a variety of other services.

I found some information which were basically stating that Google only supports U2F/FIDO protocol, but I didn't manage to get an official information or at least a reason for that.

Now, to give a bit more information on what's happening:
When trying to register for the first time:
1/ The authenticator receives a ctap2 authenticatorGetInfo request
2/ The authenticator receives a ctap2 authenticatorMakeCredential request with rpID "google.com". Upon reception of the response, the services ask for a name and then issue an error.

So basically the authenticator response is not accepted by the service. Does anyone have an idea of why this is happening?

When trying again with the same google account:
1/ The authenticator receives a ctap2 authenticatorGetInfo request
2/ The authenticator receives a ctap2 authenticatorGetAssertion request with in the allowlist the credential previously created. However this request is sent with the rpID: "https://www.gstatic.com/securitykey/origins.json" and therefore the assertion is denied.
3/ The authenticator receives a ctap2 authenticatorMakeCredential request with rpID "google.com" and with an exclude list containing the previous credential and therefore the authenticator respond with an error.

So basically, it appears that in such a situation, the service is not using the proper rpID. Does anyone have an idea why?

Note that if they are more (2 and +) credential that was registered with issue to this account, then the service try to retrieve an assertion with both "https://www.gstatic.com/securitykey/origins.json" and "google.com" rpID, which feels more correct.

Thanks for your help,

Xavier Chapron

[My1]

You likely already added the ledger as a normal security key for 2 step. 

The different rpid is part of the u2f migration mechanism. Iirc that's using "excludeAppId" on the registration, which allows the device to look for credentials made when Google was still running around with the u2f js rather than webauthn, and allows to ignore those devices too. 

This doesnt apply to your ledger so it just goes nowhere. 

The last part is making a normal ctap2 credential request and excludes the ledger as it is likely in your Google acc already but not as a passkey. 

So just delete the existing ledger entry and add it again. 

Regards My1

---

Les informations contenues dans ce message électronique ainsi que celles contenues dans les documents attachés sont strictement confidentielles et sont destinées à l'usage exclusif du (des) destinataire(s) nommé(s).

Toute divulgation, distribution ou reproduction, même partielle, en est strictement interdite sauf autorisation écrite et expresse de l’émetteur.

Si vous recevez ce message par erreur, veuillez le notifier immédiatement à son émetteur par retour, et le détruire ainsi que tous les documents qui y sont attachés.

The information contained in this email and in any document enclosed is strictly confidential and is intended solely for the use of the individual or entity to which it is addressed.

Partial or total disclosure, distribution or reproduction of its contents is strictly prohibited unless expressly approved in writing by the sender.

If you have received this communication in error, please notify us immediately by responding to this email, and then delete the message and its attached files from your system.

---

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/bdc6661a-2e96-48fa-abc6-a7c7e97f2ec1n%40fidoalliance.org.

[Xavier CHAPRON]

Hello,

Thanks for your answer My1,

The thing is the first registration is not correctly executed: the security key doesn't end up being listed in the known security keys for that account. So I can't remove it, nor probably use it.

While when trying with another application supporting only U2F, I correctly see the security key listed in my account and I'm able to rename it or remove it.

So I guess this is due to either Google account or Ledger app Security Key FIDO2 implementation.

As Ledger app Security Key FIDO2 implementation is behaving properly on all other services I have tried, I am thinking that there is something weird on Google account side?

However, I guess somebody would know if there was something not normal on Google Account FIDO2 handling?

Thanks,

Xavier Chapron

[My1]

considering google has an allow/excludelist there should be existing credentials. maybe not as Passkeys but as "security Keys for 2-Step Auth".

If you registered your ledger with 2-step prior to Google Adding Passkeys, you'd need to remove that, as google excludes those from adding to the passkey section too.

As in the Picture below (German but whatever) you can see 3 sections:

1) Automatically created Passkeys (aka android devices you connect your google acc with)

2) Passkeys created by you (as in Fido Sticks and similar devices)

2a) Passkeys (aka proper FIDO2, Resident Keys with UV and everything)

2b) Security keys only for 2 Step Verification (newly added U2F Devices, as well as anything added Before Google added actual Passkey Support)

if your ledger works in 2-step auth but not as a passwordless passkey in google, it should be in the lower section.

Regards My1

[Xavier CHAPRON]

Hello :)

Ok thank to your input, I was able to understand a bit better what is happening :

Using an U2F authentificator (Ledger device + "FIDO U2F" application):
- The security key registration works with no warning
- The security key is displayed in the list of known security keys for the account
- The security key can be used to login in as 2FA

Using my FIDO2 authenticator (Ledger device + "Security Key" application):
- The security key registration works with an error
- The security key is not displayed in the list of known security key for the account, however we see that security key is now an available method for 2FA
- The security key can be used to login in as 2FA

You can find some recording below showing the described behavior.

So basically it appears to me this is an UI issue on Google side. Does anyone know more about it?
Does the FIDO alliance as a way to reach Google regarding this?

Thanks,

Xavier CHAPRON

[My1]

One thing you might wanna try is adding a phone first. maybe they made actual passkey stuff a bit more hidden and only works when you have a phone active.

when I first enabled Passkeys I went into the security key section with a list of all my stuff (including 2 androids) where there was a button to "enable passkeys"

as when you actually add a "Passkey" as opposed to a "Security key" it will show the second like of a record being kept on your key, aka it trying to make a resident key.

[John Bradley]

Use Chrome on OSX and capture the logs.  chrome://device-log/. You mostly need the Fido one.

I suspect that the authenticator is not returning a discoverable credential for some reason.  That may explain why it is being categorized as 2FA.

The log will tell you what is going to and from the authenticator.  I can’t help with Ledger specifics.  I don’t have one.

Regards

John B.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/a85c132f-0c1c-4f28-972c-2d2d79dc95e2n%40fidoalliance.org.
<adding_FIDO2.webm><adding_U2F.webm><using_FIDO2.webm>

[My1]

Considering the prompt shown in the video, Google isn't even asking for a resident credential in the first place. When rk is active it shows a second like about a record of your visit being stored etc etc. 

[Xavier CHAPRON]

Hi,

Thanks for your help.

@John, indeed the credential is not a discoverable one because Google is not requesting for one.

Though I'm not sure why you say why it should therefore be categorized as 2FA? I have another authenticator which support only U2F, and therefore can't support RK and Google support it better (it is shown in the UI)...

Here is the relevant part of the logs where I am registrating the authenticator:

FIDODebug[17:14:50] -> {1: "packed", 2: h'D4C9D9027326271A89CE51FCAF328ED673F17BE33469FF979E8AB8DD501E664F45F1D0C034FCB1BCB4F370078C6993BC24D0AE3FBE00660287534AAF8E384BADA17B6FD8C62C65FC463A44B7C77DCB3FBE7F6543E591EEABF89CB9C90F90A39953FB8E5F0165702BAFB8714CC99D8EF8FA5B582340E99D18E29AAC861DC2DDEFA2743098F28660D88AA8E61E2D037938959EBECECDE4719AF1A426DEF4A5010203262001215820073DB8988C62A8B82BFE20AF5034ECCF113941EAE9E2C1717EFBE926E51EB2C4225820978FCC907EDABC6DD63F04366BC05894A124E07594BDC6BD133BB1939DBEDE9F', 3: {"alg": -7, "sig": h'304402206E7AA72EFD2FDE935384AF780C443615F7AA15D7F24384D5D70FE4A1F44E3A40022066DCEB7869D396157293ECBF6AB342A0E3293721B84DB029E99C72A4A1404C29', "x5c": [h'308201ED30820193A00302010202140C20109D50E9A06359A6F103E4835EBBD53B10D0300A06082A8648CE3D0403023043310B3009060355040613024652310F300D060355040A0C064C65646765723123302106035504030C1A4C6564676572204649444F204174746573746174696F6E204341301E170D3233303232333130333330395A170D3333303232303130333330395A3075310B3009060355040613024652310F300D060355040A0C064C656467657231223020060355040B0C1941757468656E74696361746F72204174746573746174696F6E3131302F06035504030C284C6564676572204E616E6F2D58204649444F2032204174746573746174696F6E20426174636820313059301306072A8648CE3D020106082A8648CE3D030107034200044656A92B559133E41BA0AD88CDA44FE817C8BA48D6F506DE0E65777FD5F2FBE2E7E868576AB504A4154FD425CA1B32FCC912F07A2AD64C718DB2BFCBACD5C4DAA33330313021060B2B0601040182E51C01010404120410FCB1BCB4F370078C6993BC24D0AE3FBE300C0603551D130101FF04023000300A06082A8648CE3D0403020348003045022100C2A76CF97D328C72F188DCFD4B19E48A0A06965D15D62409EF724F7F755780D20220433A4A610073087875E637A5205956B64DC66C9C7F28A0748B5BB5585167E7E0']}}
FIDODebug[17:14:41] <- 1 {1: h'8F3DC4465CF5A0E3A298A3D94CDB0B222A582F0BFF00C42F3711EA92D259E17A', 2: {"id": "google.com", "name": "Google"}, 3: {"id": h'474F4F474C455F4143434F554E543A313138323630343931393834333338393932353539', "name": "test2...@gmail.com", "displayName": "test2...@gmail.com"}, 4: [{"alg": -7, "type": "public-key"}, {"alg": -257, "type": "public-key"}], 7: {"uv": true}}
FIDODebug[17:14:41] The device supports the CTAP2 protocol.
FIDODebug[17:14:41] -> {1: ["U2F_V2", "FIDO_2_0"], 2: ["hmac-secret", "txAuthSimple"], 3: h'FCB1BCB4F370078C6993BC24D0AE3FBE', 4: {"rk": true, "up": true, "uv": true, "clientPin": false}, 5: 1024, 6: [1]}
FIDODebug[17:14:41] Sending CTAP2 AuthenticatorGetInfo request to authenticator.
FIDODebug[17:14:41] Android accessory discovery started
FIDODebug[17:14:41] Found 0 caBLEv2 devices
HIDUser[17:14:08] HID device added: vendorId=11415, productId=16405, name='Nano X', serial='0001', deviceIds=[4295018534], reportDescriptor='BtDxCQGhAQkDFQAm/wB1CJVAgQgJBBUAJv8AdQiVQJEIwA=='

And here is the relevant part for an authentification:

FIDODebug[17:14:50] -> {1: "packed", 2: h'D4C9D9027326271A89CE51FCAF328ED673F17BE33469FF979E8AB8DD501E664F45F1D0C034FCB1BCB4F370078C6993BC24D0AE3FBE00660287534AAF8E384BADA17B6FD8C62C65FC463A44B7C77DCB3FBE7F6543E591EEABF89CB9C90F90A39953FB8E5F0165702BAFB8714CC99D8EF8FA5B582340E99D18E29AAC861DC2DDEFA2743098F28660D88AA8E61E2D037938959EBECECDE4719AF1A426DEF4A5010203262001215820073DB8988C62A8B82BFE20AF5034ECCF113941EAE9E2C1717EFBE926E51EB2C4225820978FCC907EDABC6DD63F04366BC05894A124E07594BDC6BD133BB1939DBEDE9F', 3: {"alg": -7, "sig": h'304402206E7AA72EFD2FDE935384AF780C443615F7AA15D7F24384D5D70FE4A1F44E3A40022066DCEB7869D396157293ECBF6AB342A0E3293721B84DB029E99C72A4A1404C29', "x5c": [h'308201ED30820193A00302010202140C20109D50E9A06359A6F103E4835EBBD53B10D0300A06082A8648CE3D0403023043310B3009060355040613024652310F300D060355040A0C064C65646765723123302106035504030C1A4C6564676572204649444F204174746573746174696F6E204341301E170D3233303232333130333330395A170D3333303232303130333330395A3075310B3009060355040613024652310F300D060355040A0C064C656467657231223020060355040B0C1941757468656E74696361746F72204174746573746174696F6E3131302F06035504030C284C6564676572204E616E6F2D58204649444F2032204174746573746174696F6E20426174636820313059301306072A8648CE3D020106082A8648CE3D030107034200044656A92B559133E41BA0AD88CDA44FE817C8BA48D6F506DE0E65777FD5F2FBE2E7E868576AB504A4154FD425CA1B32FCC912F07A2AD64C718DB2BFCBACD5C4DAA33330313021060B2B0601040182E51C01010404120410FCB1BCB4F370078C6993BC24D0AE3FBE300C0603551D130101FF04023000300A06082A8648CE3D0403020348003045022100C2A76CF97D328C72F188DCFD4B19E48A0A06965D15D62409EF724F7F755780D20220433A4A610073087875E637A5205956B64DC66C9C7F28A0748B5BB5585167E7E0']}}
FIDODebug[17:14:41] <- 1 {1: h'8F3DC4465CF5A0E3A298A3D94CDB0B222A582F0BFF00C42F3711EA92D259E17A', 2: {"id": "google.com", "name": "Google"}, 3: {"id": h'474F4F474C455F4143434F554E543A313138323630343931393834333338393932353539', "name": "test2...@gmail.com", "displayName": "test2...@gmail.com"}, 4: [{"alg": -7, "type": "public-key"}, {"alg": -257, "type": "public-key"}], 7: {"uv": true}}
FIDODebug[17:14:41] The device supports the CTAP2 protocol.
FIDODebug[17:14:41] -> {1: ["U2F_V2", "FIDO_2_0"], 2: ["hmac-secret", "txAuthSimple"], 3: h'FCB1BCB4F370078C6993BC24D0AE3FBE', 4: {"rk": true, "up": true, "uv": true, "clientPin": false}, 5: 1024, 6: [1]}
FIDODebug[17:14:41] Sending CTAP2 AuthenticatorGetInfo request to authenticator.
FIDODebug[17:14:41] Android accessory discovery started
FIDODebug[17:14:41] Found 0 caBLEv2 devices
HIDUser[17:14:08] HID device added: vendorId=11415, productId=16405, name='Nano X', serial='0001', deviceIds=[4295018534], reportDescriptor='BtDxCQGhAQkDFQAm/wB1CJVAgQgJBBUAJv8AdQiVQJEIwA=='

We can see that the authenticator expose in the AuthenticatorGetInfo that it support rk, but the makeCredentials request only ask for uv.

Does it helps?

Thanks,

Xavier Chapron

[My1]

Have you tried adding a phone first? I'd guess Google only allows a passkey after you added a phone and then enable passkeys in the security key page specifically (there was a button for that)

Specifically also note that in your videos the word passkey iirc isn't mentioned at all

[John Bradley]

Both are make credentials.   

The authenticator is not asked to make a discoverable credential.  

If Google were trying to make a passkey they would have set discoverable preferred. 

From the video you may be using a workspace account that doesn’t support passkeys yet.

I don’t see any of the dialogs I would expect in the video.   

Try this from, a gmail.com account.   A ledger.fr workspace account won’t work.

The screen shot where you have passkey registerd with the add passkey button at the bottom is what you want.

I did find one bug with appIDexclude that Google is working on, but that doesn’t look like your problem from the logs that you included.

John B.

[Xavier CHAPRON]

Hello :)

Ok, I think I start to understand more and more what is happening.

I was adding my authentificator as a "2-Step Verification" => "Security Key" device. While doing so:

• Google request for a credential without rk,
• the key is added as a "2-Step Verification" method that can be used but is not displayed in "2-Step Verification" => "Security Key" list
• I just discovered that the key is displayed (and manageable) in the "Passkeys" list

Now, thanks to both your help, I found out that I can register my authentificator directly as a "Passkey". While doing so:

• Google request for a credential with rk if supported by the authentificator,
• the key is added as a "Passkey" method that can be used and is displayed in "Security Key" list

Now I still have small questions about it:

• Are they going to improve the UX of the flow where a "2-Step Verification" => "Security Key" is added but ends-up in "Passkey" section after an cryptic error message?
• At the end of passkey registration, there is a pop-up requesting for access to "the make and model of your security key". If I allow it, the creation fails, while if I deny it with "Skip" the creation works. That feels a bit weird. Do you know what happens under the hood?
  
• While adding a passkey, Google request for a credential with rk when supported by the authentificator. But it also accept authentificators not supporting it and anyway it is not using it at login as it request the user login first and can therefore populate the getAssertion allowList. I feel like rk credential should not be used in such situations. Do you know the reason why Google (and probably other services) made that choice?

Thanks again,

Xavier Chapron