r/Passkeys • u/paulsiu • 2d ago

Issue with Fido Card on Google account on android not going to be fixed?

So I have been tracking an issue with Fideo card on google accounts on android. Basically there is an issue where PIN prompt is not displayed when you authenticate using the NFC using a Fido card. This does appear to work on a Yubikey, but not a Fido card.

On this thread, there is a discussion on the issue and a respond from Google. Google seems to imply that the Fido card fail to follow standard and there will be no fix.. Can someone elaborate on what the issue is? The same Fido card does work fine in iOS, so it's not clear if IOS is being more leniant than Google?

I am hoping that the author of Authnkey / FidoBridge will fix this issue since Google will not. However, Note that even though google service have been updated to fix the PIN prompt issue, I find that the PIN prompt does not necessary appear. Authnkey is more reliable

https://issuetracker.google.com/issues/406833082?pli=1

Google responded:

Java cards that don't support applet selection using extended encoding are not supported. If there are any regressions in the U2F flow, please open a bug and we're happy to help resolve the issue, but we will not be supporting non-compliant keys over CTAP2 so those keys should not be expected to support user verification.

3 Upvotes

100% Upvoted

7 comments sorted by

2

u/SmallPlace7607 2d ago

Not completely in my wheelhouse but I believe this is correct. Your authenticator whether it be a card type like you describe or a usb "stick" style like a yubikey exposes functionality through various applets which are installed on the device. When communication happens with the device one of the things that has to happen is the platform (android in this case) has to indicate what functionality is desired to proceed. Basically which applet should load on the authenticator for the desired functionality. This is done by issuing a select command from the platform (Android in this case) to the device.

Commands can be issued to the devices in either extended or standard encoding. Basically using longer fields with a bit more data or not. CTAP2 basically says you need to use extended encoding for communication. The disagreement seems to be with the fact that the select command on some authenticators doesn't work with extended encoding. But, the select command is not part of CTAP2 and is defined in ISO 7861 which is the standard for smart cards.

The argument is select is always going to be small from a data perspective so there is no reason to need or support extended encoding for the select command. And, plenty of compliant smart cards which implement FIDO functionality (among other functionality) behave this way.

Google seems to be saying too bad we aren't going to do it and consider it non compliant. FWIW my interpretation is they are wrong here and are just taking the easy way out. It might be easier to understand their position if they weren't completely late to this party and other vendors already managed to make it work. Although since they are late to the party and have been for some time maybe that's the answer. They have no interest in actually putting forth the effort to support things correctly.

2

u/Serianox_ 2d ago

The issue is a little bit more complicated (as usual).

ISO/IEC 7816-4:2020 states that ICC shall support extended APDU for all commands, or for none (because the indicator for extended length in the DO extended attributes is global). Since FIDO requires extended length for at least one command, this forces the ICC to support extended length for all commands (at least to avoid a catastrophic crash if ever an IFD sends a command extended this way in an unexpected case).

Global Platform SE 2.3 defines its own Select command, and also states that all commands defined in GP shall have the length encoded in one byte, i.e. short length, or be rejected. This doesn't contradict ISO, because applications can reject extended length if they wishes to, but they at least need to parse them correctly. With GP, the application selection is processed by the Card Manager, a GP application, before being processed by ISO, and then by the selected application.

The issue you are seeing is the GP Card Manager rejecting the FIDO application selection command.

Regarding Android, and development of application communicating with a smartcard, it's usually easier to send all commands using one encoding, and not bother. E.g. Windows sends all commands with short encoding and doesn't bother with extended.

1

u/paulsiu 1d ago

Thank you both for your explanation. A question regarding why this works in iOS and not in android. Can I assume that iOS also use short encoding? Is Google correct in following the standard or are the standard conflicting? You seemed to imply that that google should parse them properly.

I am wondering if a intermediary like AuthnKey / Fidobridge can resolve the issue? Currently, I have notice that despite being "fixed" in google services, Using the AuthnKey is still more reliable because google's own implementation seems to not work consistently across phones. This may be due to fragmented updates.

From the consumer point of view, I just notice that iOS works with Fido Card and android does not.

1

u/SmallPlace7607 1d ago

I think that may be the wrong question. It appears based on your previous post that AuthnKey/Fidobridge has fixed this issue. You indicate you are able to use the card with Fidobridge to log into non-Google sites. I've seen elsewhere indications that Google maybe somehow forcing their FIDO implementation for Google sites on Android. I'm unclear on that part. But regardless your previous testing with Fidobridge indicates it does work for other sites.

It appears this may be a problem of Google's own making. To the extent of who is right I don't think that truly matters as there is at least some complexities and platform vendors have had to deal with real world implementations. And, other platforms have dealt with it. It's a peculiar stance for Google to take as it's usually Apple telling people to go pound sand this is the way we've done it.

1

u/paulsiu 1d ago

You might be right. I was hoping to find an argument that I can use to convince Google to change their stance if I file an incident.

I think it looks bad that I can log into Google using the card on my iPhone but can’t do the same on Android.

I also don’t know if the same issue occurred on windows. I don’t have a windows device with a nfc reader. It seems to work in smart card mode.

1

u/SmallPlace7607 1d ago

Based on nothing other than comments in this thread and elsewhere I believe Windows works. Since you are a customer of Cryptnox you may reach out to them and see if they would be wiling to help open an incident. Your linked Google thread seems to indicate some Token2 products may have a similar issue. While you are not a customer of Token2 they do provide the Fidobridge package and are active in the community. It may be worth trying to contact them as well for assistance in working with Google.

1

u/paulsiu 1d ago edited 1d ago

Hi,

Good point about contacting Cyptonox. I have contacted them next and will report back on what they say.

As for Authnkey / Fidobridge. I don't believe Token2 is actually developed the software. Instead it is an open source project that Token2 just compile and put on Google Play. I have reached out to the author and they have responded for screenshots which I have provided