Authenticators
Overall authenticator information
Authenticators are used in the context of FIDO UAF. For the purposes of this documentation, authenticators refer to the devices used for authentication, whereas authentication methods refer to the actual PIN-based or biometric means of authentication. Authenticators are responsible for user verification as well as maintaining the cryptographic material required for authentication. A FIDO UAF authentication method guarantees that a user is securely verified and authenticated.
FIDO UAF authenticators are fully specified by the FIDO Alliance.
The authentication methods provided by the Nevis Mobile Authentication SDK are:
- Application PIN authentication
- Biometric face Authentication (Android only)
- Android fingerprint authentication (Android only)
- TouchID authentication (iOS only)
- FaceID authentication (iOS only)
Any supported mobile devices integrating these software-based authentication methods can immediately provide FIDO authentication to users. No other hardware-based FIDO UAF authenticators are needed on the mobile device.
The authentication methods provided by the Nevis Mobile Authentication SDK share the following main functionalities and properties:
Protection of key material
The key material is generated and stored securely by the authenticator.
User verification
User verification is carried out in any FIDO UAF operation where the authenticator accesses the private key.
Sign challenge
The signing of a challenge is an internal SDK process that comes into play during the authentication and transaction confirmation FIDO operations.
One credential
An authenticator supports only one credential at a time. This means that a user can use one authenticator to authenticate only one account. In the FIDO context, the authenticators do not support the concept of the persona.
First-factor bound authenticator
The authenticators are of type first-factor bound authenticator. For details, refer to the FIDO UAF specification.
Surrogate basic attestation
Since the attestation key of software-based authenticators cannot be sufficiently protected, the authenticators support only surrogate basic attestation. This means that they are also called non-attested authenticators.
It is possible, and recommended by the FIDO Alliance, to register more than one authenticator.
An authenticator is the most critical security element, because it manipulates sensitive user data. Protecting it from attackers is crucial. For more information on how to protect an authenticator, see Security Considerations.
Available authentication methods
Application PIN
The Application PIN authentication method ensures that only authorized users are allowed to use the key that is stored in the secure storage. An authorized user is a person who knows the correct PIN and provides it.
The Application PIN authentication method uses a PIN defined by the user during registration. The PIN is specific to this authenticator and is not bound to any specific FIDO registration. This means that a user does not necessarily need to define a new PIN for subsequent FIDO registrations on the same device. Once one is set, the PINs are completely independent.
On user enrollment – that is, setting a PIN – the mobile application asks the user to enter a new PIN that matches the given format/policy, plus confirmation of the provided value. The confirmation value ensures that the PIN does not contain a typo. The operation fails if the two values are not the same, or if the PIN does not match the expected format. The Nevis Mobile Authentication SDK is responsible for validating the input format and storing the PIN in the secure storage.
The SDK is also responsible for carrying out user verification – that is, PIN verification. If the SDK can successfully match the PIN transferred by the mobile application, the SDK can then use the required private key in the FIDO operation.
It is the responsibility of the application to define and present the appropriate UI to the user to get the PIN value. The application is provided with a specific format to be used for the PIN and is expected to return the input values to the SDK.
This PIN is not the same as the one defined in the device system settings, that are used with the device lock screen.
Since the PIN is stored locally on the device, the user can change the PIN at any time, even if the device has no data connection to the backend.
To change the PIN of a user, the mobile application must obtain the following values to be passed to the SDK:
- The current PIN
- The new value
- A confirmation of the new value
The current PIN is verified before the value is changed. The operation fails if the current PIN is wrong, or if the new value and confirmation value are not the same or do not match the expected format.
On user verification, the only value that is required by the SDK is the current PIN entered by the user.
Brute force attack prevention
The PIN Authentication method is protected from brute force attacks. For details, see Brute force attack prevention in the Security Considerations chapter.
Android biometric
The Android biometric authentication method is available for Android OS versions with API level 29 (Android 10) or higher.
The authentication method makes use of the new Android biometrics APIs introduced with this API level.
The authentication method uses the biometric authentication method based on the device hardware capabilities. This means depending on the device model, either fingerprint scanning, facial recognition, or another biometric method supported by the API is offered to the user.
The Android biometric authenticator only supports Class 3 biometric sensors. This is limited by the official Android API.
The Android Biometric authenticator will not show Face Authentication as an option for most devices, because currently only the face recognition biometric sensor of the Google Pixel devices is Class 3.
Nevis recommends using this authentication method instead of the older Android fingerprint authentication method.
Android fingerprint
The Android fingerprint authentication method relies on the Android FingerprintManager which was added in API level 23 (Android 6) and deprecated in API level 28 (Android 9).
This authentication method requires app developers to supply their own dialog or screen for the fingerprint prompt. This is a severe drawback.
Projects should always use the newer Android Biometric Authentication method which uses the BiometricPrompt API, as it uses a system-provided dialog when starting authentication. As devices have different types of biometric authentication, it is more practical to have a system-provided authentication dialog, since the method may vary by vendor and device.
Nevis recommends only using this Authentication method for supporting Android OS versions below Android 9. All newer Android OS versions should only offer the newer Android Biometric authentication method.
The overall capabilities and restrictions of the TouchID authentication method also apply for the Android Fingerprint authentication method.
TouchID
The fingerprint authentication method ensures that only an authorized user is able to access the key that is stored in the secure storage. An authorized user is a person who registered a fingerprint on the device.
It is possible for that more than one person to register their fingerprint on the device. In this case, the fingerprint authentication method cannot distinguish between these users, and any one of them is considered to be an authorized user.
The fingerprint authentication method uses the fingerprint managed by the operating system of the device, and does not store additional ones in the SDK. This authentication method is only available on devices with a fingerprint sensor.
Since the Nevis Mobile Authentication SDK does not directly manipulate biometric data, user enrolment takes place outside of the SDK. Similarly, user verification is triggered by the SDK but verification itself is carried out completely by the OS. The OS only informs the SDK if there is a match or not. The biometric data of the user never leaves the operating system of the device.
FaceID
The FaceID authentication method is only available on iOS devices that support FaceID. This authentication method behaves in a similar way to fingerprint authentication. FaceID authentication, like fingerprint authentication, uses the biometric capabilities of the device.
Device passcode fallback option
- Only available for iOS for all available biometric authentication methods.
- Only available for Android when running API level 30 (Android 11) or later with the biometric authenticator.
- Only available for new registrations created with SDK version 2.0.0 or higher.
From version 2.0.0, all biometric authentication methods are configured to enable the device passcode fallback option. In case the biometric verification fails, the device offers an alternative (fallback) way of verification to the user, which is entering the device passcode. Enabling this feature for existing registrations made with SDK versions prior to 2.0.0 is not possible. To use this feature, the aforementioned registrations have to be deregistered, and new ones have to be created using SDK version 2.0.0 or higher.
Authentication method security comparison
The authentication private key is a highly sensitive asset. To enable as much protection as possible, the asymmetric key pairs are stored in hardware-backed keystores. The authentication methods differ in the way they access the key in the keystore:
- Fingerprint authentication requires the user to scan their fingerprint. If there is a fingerprint match, then the private key is unlocked to carry out the cryptographic operations.
- Application PIN authentication requires the user to provide a PIN. If there is a PIN match, then the private key is unlocked to carry out the cryptographic operations.
The important difference related to security is where matching takes place:
- Application PIN authentication matching takes place in the Nevis Mobile Authentication SDK itself.
- Fingerprint authentication matching is carried out in the secure part of the system.