FIDO mobile app

[Sergei Tsoganov]

Hello, We're investigating the potential of using a mobile app as a FIDO authenticator, similar to the solutions provided by companies like Hypr and IDmelon, especially for offline authentication on iOS and Android devices. We're looking for some assistance in this area:

1. What are the key specifications and workflows that need to be considered for this implementation?
2. Are there any mobile apps currently available that function as a FIDO key for desktop or web resource access, akin to those offered by Hypr and IDmelon?
3. If someone has experience in this field, could you please share any technical details or the architecture involved?

We would greatly appreciate any help or information on this matter!

Estonian Internet Foundation

[Tim Cappalli]

You would create a credential provider, that plugs into the OS using native platform APIs. These passkeys would be available locally, and to other devices via Cross-Device Authentication (which is handled for you by the client platform(s)).

Android: Integrate Credential Manager with your credential provider solution  |  Android Developers

iOS: ASPasskeyCredentialRequestParameters | Apple Developer Documentation

--
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/568d91dc-43b8-4c8d-8ee6-0f5f596384fdn%40fidoalliance.org.

[My1]

Although the key point is that unless you have a device new enough for Android 14 or iOS17 you cannot really use these APIs, which is kind of a problem at least for now.

As someone who has used IDMelon already (prior to Android 14 obviously), when I used it it only provided its functionality towards other devices be it over an Application/BT-based pairing with the PC that runs the client, or a Hardware device in case the application pairing cannot be used, however it was not available to the phone itself, which can be a problem.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/SJ0PR00MB1141FCE0E0C34F23ABB9EAAA95B4A%40SJ0PR00MB1141.namprd00.prod.outlook.com.

[rjhal...@gmail.com]

Sergei,

 

I implemented FIDO2 authenticator app for Android and iOS some time ago. Much has changed since then so some of this may no longer be as relevant.

 

Documentation available from FIDO Alliance and W3C is excellent and if followed makes implementing the core FIDO2 functionality not too difficult.

 

But, areas where documentation is very poor to non-existent I found especially challenging:

 

1. Bluetooth was a huge challenge in the 2018/19 period. It’s gotten better but I still find it a challenging area in part a result of BT implementation differences device to device. Passkey may help smooth this out a bit.
2. Securing the cert and private key is imperative and another challenging area. Keep in mind, SE is not assured to exist on all phones.
3. Securing the app from ALL phishing attacks is a challenge, esp in view of plain text messaging.
4. One final area relates to securing the app from rooted device, riru, and what not. It’s a bigger problem area than most would believe and it does apply to both formats although less so on iOS devices.

 

Good luck,

 

Rick

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CACHSkNqGt533bY829fG8J0YdiFJHQ4dBczyc_%2BFW%3DOLtFtwAJA%40mail.gmail.com.

[Sergei Tsoganov]

Tnanks a lot!

We're currently delving into the world of FIDO authentication and have a specific query regarding its offline capabilities. I'm particularly interested in understanding how it functions in offline scenarios. Could anyone provide technical insights on the following aspects?

How does FIDO authentication technically operate when there's no internet connection? What are the key components and processes involved in validating a user's identity offline?

In the context of offline authentication, where is the user's public key stored? How is it securely managed and accessed during the authentication process without compromising security?

[rjhal...@gmail.com]

To answer your question requires an understanding of what you mean by “offline”. At minimum, use of FIDO2 requires a user, an authenticator, a relying party, and a user record. In theory these could all be one and the same but to what end? That said, then there need be some form of connection between user + authenticator to RP + user record.

 

As for you specific questions, answered out of order.

 

FIDO2 does not validate a users identity. It at best validates presence of a human and their use of a specific device.

 

FIDO2 typically does not require the internet to operate. Its operations occur between the authenticator device which the unknown human has and a FIDO Client device which the unknown human has access to.

 

The connection between these is expected to be either Bluetooth, USB, or NFC but in fact it could be any method of comms in roll-your-own scenarios.

 

The user record with which the FIDO2 device forms an affinity is, from the user + authenticator pov, in the either as is the relying party. They could be within immediate domain of FIDO Client.

 

Affinity of authenticator device to user record is formed by a registration ceremony that requires all principals. Once registered it is then possible to perform authentication ceremonies.

 

The ceremonies take place between the authenticator device and the FIDO Client and typically this occurs locally over the channels mentioned above. As such there is no internet involvement in either ceremony. But of course consideration for the relying party and user record need be made.

 

The public is made public as part of the registration process. It typically becomes part of the user record. Where, how, and how securely that record is stored is up to the relying party. I’m aware of no specific requirements nor need for them but of course the user record should be secure wherever it is.

 

Typically the public key travels from authenticator to user record once during the registration ceremony. From that point forward it is used in creation of challenge messages and in part for validating challenge message responses. These activities should be secure but are not otherwise defined.

 

You didn’t mention but I’ll toss it out that the critical components, private key and certificates, MUST be securely stored are on and within the immediate domain of the authenticator device. If/when those are compromised the user account is in jeopardy of becoming a DBIR statistic.

 

Rick

[My1]

to elaborate a little, while FIDO does not check for a user's identity, as in the FIDO Protocol does not check if you are "Sergei Tsoganov", but it does have "user verification, aka it can check via PIN, Biometrics or similar whether the person is authorized by the one who set up the device, so a FIDO device knows a PIN, finger or whatever and can therefore infer if the user would be you or someone you gave the authorization to use it by giving them your PIN.

in regards to offline, the current way phones do it, with caBLE iirc does not work offline as it uses Bluetooth merely as a proximity check before sending the data over the Internet. not sure if cross-device over USB actually transmits the data over the USB too, if yes, that would work.

however if you had a BT-enabled FIDO device or an app that actually transmits the data over BT it should work if there is no internet connection as long as the device that has the website open can reach it (e.g. in an intranet) and the phone might not need any network at all if you can find a way to move the data.

"Typically the public key travels from authenticator to user record once during the registration ceremony. From that point forward it is used in creation of challenge messages and in part for validating challenge message responses. These activities should be secure but are not otherwise defined."

not quite, the public key generally only gets sent on registration, after that it only is on the Database of the Relying party and the Authenticator can infer it either by the credential being resident or when it obtains the credentialID from the RP.

but when creating a challenge the challenge itself is generally random and if you use non-resident credentials, the credential ID will be sent along (but NOT the public key), it will equally not be sent with the response the response (aside from metadata which helps verification only really has the credential ID and the sig)

[rjhal...@gmail.com]

Not nitpicking but, there is nothing in the FIDO2 specifications that require user identity proofing over and beyond that of a gesture. Never has been and so far as I know, not in the works. I have a number of Titan and Yubi keys that work just fine and none save one incorporate identity proofing.

 

That said, indeed it’s a really, really good idea to do so and to do so such that identity proofing occurs as a part of and inseparable from the authentication ceremony. For example, the user gesture is not accepted until the user identity has been proofed. For several reasons, the FIDO2 cell phone app reliance on screen unlock is a really bad idea. There is no way an app can learn: is screen lock used?, what type is it?, when was it last used relative in time to the authentication ceremony? There is no assurance of its type or even of  its use in some cases and neither OS provides access to the specifics of its use, type, active state, and so on.

 

Rick