Mobile app as universal authenticator

[Michael Velbaum]

Hi,

There have been previous question on how to use a mobile app (on iOS and Android) to authenticate PC clients, but I have the opposite question - is it possible to use the same mobile app as an authenticator for other apps on the mobile device (browser, etc..)?

What is even the expected behavior in this case?

With TOTP, you could just use the same mobile authenticator app for both mobile and desktop apps, but I'm not sure what the best practices are when it comes to WebAuthn.

From what I see on iOS (I have an iPhone), when I test various WebAuthn sites on Safari I get prompted to use a security key - but there is no option to delegate the authentication process to some 3rd party app. Is there a way around that, or is this by design?

Thanks!

[rick.h...@att.net]

Hi,

 

One approach is the hybrid App, an App that acts as a mobile CTAP2 authenticator via BLE and as a local authenticator via ASM API. I suppose the same could be done using NFC in the remote case but I have yet to explore that option.

 

Rick

--
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/892aee7a-6852-4cbc-8453-35a87d02e4d8n%40fidoalliance.org.

[Michael Velbaum]

Hi Rick,

A few questions:

1. Are you saying that the app should pose as a virtual BLE device, and then have the iPhone pair with it? Is that even possible?

2. I'm not familiar with the ASM API, any chance you could give a link?

3. Regarding NFC - not sure what you mean here. You still need some external NFC device for this, no?

[Arshad Noor]

In theory, you can build a native mobile app on Android 9+ using the
FIDO2 protocol by working with this recently announced FOSS library to
accomplish what you want - the library is available at these 2 sites:

https://sourceforge.net/projects/strongkeyfido/files/v4.4/sampleapps/sacl/

https://github.com/StrongKey/fido2/tree/master/sampleapps/java/sacl

The presentation of the sample app shown in this YouTube video recording
reflects using the library to demonstrate Strong Customer Authentication
(SCA) for a frictionless PSD2 transaction:

https://www.youtube.com/watch?v=tp5i9_e7xEY&index=6 (SACL at 5:00)

However, the library is capable of SCA for any purpose - including
getting confirmation for login to other apps. The source code available
at both SourceForge and Github demonstrate the end-to-end process of a
transaction being confirmed with a FIDO2 signature. While the demo app
is designed to show PSD2-style "dynamic linking" transactions, your
use-case will follow a different flow.

Arshad Noor
StrongKey

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

> <mailto:fido-dev+u...@fidoalliance.org>.

> To view this discussion on the web visit
> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/892aee7a-6852-4cbc-8453-35a87d02e4d8n%40fidoalliance.org

> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/892aee7a-6852-4cbc-8453-35a87d02e4d8n%40fidoalliance.org?utm_medium=email&utm_source=footer>.

[Michael Velbaum]

Thanks Arshad!

At this point my issue is to figure out how to do something like this for the iPhone. As the modal screen Safari displays for authentication seems to require using only NFC or Lightning connected devices (and possible BLE?).

[Patrice Thibodeau]

Is this something similar to what Akamai have announced? 

https://www.akamai.com/us/en/multimedia/documents/white-paper/todays-mfa-is-it-a-security-illusion.pdf

[Arshad Noor]

Yes and no, Patrice.(Apologies for the mixed answer, but this is where things get nuanced in the FIDO ecosystem).

The PDF you referenced has this sentence on the last page: "The Akamai MFA service introduces a new authentication factor. It digitizes the security of FIDO2 with just a smartphone and a web browser, and combines it with the easy-to-use, familiar experience of a push notification — which can be used across any platform as a roaming authenticator."

Clearly, they have created a capability that leverages the FIDO2 protocol on a mobile device, using the native browser on the device, to strongly authenticate the user when they attempt to login into some  application. This is no different from traditional "push-notification" apps that prompt for confirmation of some action on the mobile. The difference is that the Akamai capability is using the FIDO2 protocol leveraging the browser on the device. Their capability may be integrated with TouchID/FaceID on iOS devices and with similar biometric capabilities on Android - I don't know since I don't use any third-party MFA service, including Akamai's - to any website/application.

What the StrongKey Android Client Library (SACL) does goes further than most FIDO2 implementations - I can, currently, only speak for the Android platform since we don't have an iOS library (yet):

1. It is a native implementation in Java and is intended to be used with Java rich client apps (RCA) on Android 9 (Pie) or greater - not with browsers;
2. It leverages the AndroidKeystore cryptographic provider for key-management, which leverages the Trusted Execution Environment (TEE) or a Secure Element (like the Titan chip Google introduced in their Pixel devices) to generate, store and use key-pairs securely within the device;
3. It generates and delivers an Android Key Attestation to the relying party (RP) at FIDO registration time, to provide a fair amount of detail about the mobile device and its security characteristics, along with a chain of digital certificates generated by the device's TEE firmware/software, attesting to the veracity of the key-pair as claimed by the hardware manufacturer. This attestation can be verified separately by the RP to determine whether it chooses to trust such a device for its business purpose. Currently, to the best of my knowledge, the browser based FIDO registration process delivers only a SafetyNet or a Basic Attestation. While this provides some levels of assurances about the device to the RP, it does not quite match the depth of an Android Key Attestation.  We have placeholders in the SACL to include the SafetyNet Attestation in the future if there is interest in it, but for now, we believe the Android Key Attestation provides stronger claims about key-protection on an Android device than SafetyNet does;
4. It leverages capability available in StrongKey's FIDO Certified FIDO2 Server to receive transaction details - whatever that transaction might be from a business perspective - generate a unique challenge for that specific business transaction, and receive it from the FIDO server;
   
5. Upon receiving this challenge, it leverages Android's BiometricPrompt API to present elements of the business transaction in a secure display and prompt the user to supply their biometric data to confirm the transaction. Upon verifying the biometric template, the BiometricPrompt API is permitted to call AndroidKeystore to digitally sign the challenge for a response to the business application. The FIDO server verifies the signature and provides the business transaction details - including necessary cryptographic and FIDO data elements confirming the transaction - to the business application. In the payments context, this response from the StrongKey FIDO Server can be used to relay the information to banks and/or other parties for business use-cases.

A browser-based FIDO2 "transaction" cannot associate the FIDO digital signature to a specific business transaction because  no browser has implemented the Transaction Authorization capability in any browser to the best of my knowledge. Since no implementations exist for the extensions in any browser, the W3C policy required that it be removed from the Level-2 specification. Of course, browser manufacturers can still choose to implement the extension based on the Level-1 spec if they wanted to, but that's a business decision they have to make.

While FIDO standards do not cover how to implement transaction authorization in the FIDO2 protocol (outside of the WebAuthn Level-1 spec), nothing prevents innovative companies from delivering the capability leveraging underlying cryptographic primitives available on specific platforms. That is what we chose to do.

Hope this helps.

Arshad Noor
StrongKey