Skip to main content
Version: 3.8.x.x RR

Android release notes

Android SDK 3.8.0 - 07.11.2024​

General changes and new features​

  • NEW: ClockSkewTooBig error is now also returned as AuthCloudApiError if such error occurs during registration. (NEVISACCESSAPP-5994)
  • NEW: Two experimental APIs that allow to check and synchronize configuration mismatches between client and backend has been added. (NEVISACCESSAPP-5821)
  • NEW: The new JwsAuthorizationProvider allows to execute deregistration without authorization requiring user interaction. (NEVISACCESSAPP-5475)
  • NEW: Automatically migrating wrongfully created non-unique device IDs (NEVISACCESSAPP-6044)
  • FIXED: We changed the credential validation order to be aligned with the iOS implementation. (NEVISACCESSAPP-6079)
  • UPDATE: The hardening framework has been upgraded to the latest version. (NEVISACCESSAPP-6128)
  • UPDATE: The SDK uses elliptic curve keys with a P-256 curve to decrypt out-of-band payloads (with JWE) and to sign requests (using JWS). (NEVISACCESSAPP-6130)
  • UPDATE: With nevisFIDO version 7.2411.x or newer, the SDK uses elliptic curve keys with a P-256 curve for new FIDO UAF credentials instead of RSA. (NEVISACCESSAPP-6123)
  • UPDATE: The SDK ignores invocations to OsAuthenticationListenHandler.resumeListening, if OsAuthenticationListenHandler.pauseListening is not invoked before. This allows the application to call OsAuthenticationListenHandler.resumeListening without checking whether the authentication was paused before. (NEVISACCESSAPP-6200)
  • UPDATE: With nevisFIDO version 7.2411.x or newer, the SDK is able to use FIDO UAF Basic Full Attestation for new FIDO UAF credentials instead of FIDO UAF Basic Surrogate, if the device contains a Google certified TEE. (NEVISACCESSAPP-6141)

Breaking Changes​

Android SDK 3.7.0 - 12.07.2024​

General changes and new features​

Android 6 / API Level 23 deprecated

As of Android SDK 3.7.0, API level 23 support is deprecated.

Non-unique device identifier

This release addressed an issue regarding the device identifier (NEVISACCESSAPP-6029). Refer to the known issues entry in the appendix section.

  • NEW: A new experimental API (PendingOutOfBandOperations) to retrieve pending out-of-band operations has been added. This is referred to as the fetch channel. (NEVISACCESSAPP-4862)
  • NEW: A new MetaData API to retrieve Nevis Mobile Authentication SDK version and SHA-256 hash of the signing certificate of the application that includes the SDK is available. (NEVISACCESSAPP-5897)
  • NEW: The SDK supports wildcard Facet IDs. (NEVISACCESSAPP-5664)
  • NEW: first SDK initialisation time has been reduced. (NEVISACCESSAPP-5466)
  • FIXED: The error consumer of the Authentication Cloud registration operation is invoked from the main thread. (NEVISACCESSAPP-5849)
  • FIXED: the SDK includes the deviceId attribute in the registration Send UAF response when an error occurs. (NEVISACCESSAPP-5674)
  • FIXED: the device ID created by the SDK is unique. (NEVISACCESSAPP-6029)
  • CHANGED: do not rely on the platform default key length when creating AES encryption keys. (NEVISACCESSAPP-5948)
  • UPDATE: The hardening framework has been upgraded to the latest version. (NEVISACCESSAPP-5711)
note

Upgrade the finalization tools if you have a previous installation of them. Install the latest finalizer binaries and Finalizer Gradle plugin from the SDK distribution package. See the Finalization chapter for details.

After the installation of the latest finalization tools, update the used Finalizer Gradle plugin verison in your build.gradle file. Modify the line:

classpath group: '*.protect-android', name: '*.protect-android', version: '1.1.0'

to

classpath group: '*.protect-android', name: '*.protect-android', version: '1.2.0'

Replace the placeholders (*) in the gradle classpath below with the real package namespace as indicated by the finalizer file name.

Breaking Changes​

  • NEW: A new alphanumeric Password Authenticator is available. Note that this requires the nevisFIDO 8.2405.0 component version, otherwise you will need to manually extend the metadata and policy configuration files in nevisFIDO to support this new authenticator type. In this case refer to Default Nevis Authenticator Metadata to obtain the metadata statements and don't forget to add the authenticator AAIDs to the policy file(s). This is classified as a breaking change as depending on your implementation you may need to adapt your code when filtering or listing the available authenticators. (NEVISACCESSAPP-5406)
  • CHANGED: the device passcode cannot be used as fallback with the biometric authenticator if the credentials must be invalidated when new biometrics are added in the OS settings. Setting invalidateOnNewOsBiometrics and allowDevicePasscodeAsFallback to true when creating registration operations will throw an IllegalArgumentException. (NEVISACCESSAPP-5583)

For more information, see API references.

Android SDK 3.6.2 - 19.03.2024​

  • UPDATE: The hardening framework has been upgraded to the latest version. (NEVISACCESSAPP-5610)

Android SDK 3.6.1 - 24.01.2024​

  • CHANGED: For new installations, the device ID generated by the SDK does not change after the application is uninstalled and installed again. (NEVISACCESSAPP-5474)

Android SDK 3.6.0 - 16.01.2024​

  • FIXED: The SDK does not accept unsafe ciphers (such as SHA-1 ciphers) to establish connections. (NEVISACCESSAPP-5310)
  • NEW: The PinPolicy has been extended with the validatePinForEnrollment and validatePinForPinChange methods. These methods allow implementing custom PIN policies of any nature.
  • FIXED: The SDK does not time out during enrollment if the user keeps providing invalid PINs. (NEVISACCESSAPP-5370)
  • UPDATE: The hardening framework has been upgraded to the latest version. (NEVISACCESSAPP-5427)
  • NEW: The SDK supports Android Gradle plugin versions from 7.0.0 to 8.2.1. (NEVISACCESSAPP-5427)
  • NEW: The SDK support supports JDK 11 and JDK 17. (NEVISACCESSAPP-5427)

Breaking Changes​

The API is backwards compatible with the previous 3.x versions, but there are some breaking changes that affect how to use the SDK to build your application using the release flavor:

  • You must copy a binary in the machine building the application and set the FINALIZE_ANDROID_ROOT to point to the directory where the binary is copied.
  • The name of the finalization JAR file has changed.

See the Android installation for details.

Android SDK 3.5.1 - 17.11.2023​

  • FIXED: We fixed an issue which caused improper authorization cookies being returned by the SDK in case the Accounts were registered against multiple backends (NEVISACCESSAPP-5386).

Android SDK 3.5.0 - 09.10.2023​

  • FIXED: The SDK relies on the system CA certificates to validate the server certificate and is strict doing hostname validation. (NEVISACCESSAPP-5210)
  • FIXED: The user interaction timeout is not triggered during PIN authentication if the authenticator is in cool down mode. (NEVISACCESSAPP-5225)

Breaking Changes​

The DeviceInformation is a required parameter during registration, if there is not a DeviceInformation already defined (that is, it is required for the first registration).

Android SDK 3.4.1 - 29.08.2023​

  • FIXED: We fixed the bug where the SDK crashed when the backend returns cookies containing non-URL characters in Path. (NEVISACCESSAPP-5168)

Android SDK 3.4.0 - 23.08.2023​

Breaking Changes​

  • Since the new device passcode authenticator has been defined, you may need changes in your code to handle it properly.
  • The signature of the Authentication.onError method is changed. This may break your build when upgrading to SDK 3.4.0. Replace the references to Consumer<OperationError> by Consumer<AuthenticationError> in your Authentication code if needed.
  • The default value of the Registration.invalidateOnNewOsBiometrics, OutOfBandRegistration.invalidateOnNewOsBiometrics and AuthCloudApiRegistration.invalidateOnNewOsBiometrics methods has changed. If your code was not setting the value when building the registration operation, you need to set the value to keep the previous behavior on new registrations. This change does not affect already existing registrations.
  • The default value of the Registration.allowDevicePasscodeAsFallback, OutOfBandRegistration.allowDevicePasscodeAsFallback and AuthCloudApiRegistration.allowDevicePasscodeAsFallback methods has changed. If your code was not setting the value when building the registration operation, you need to set the value to keep the previous behavior on new registrations. This change does not affect already existing registrations.

Android SDK 3.3.0 - 30.06.2023​

  • NEW: We now support invalidating the FIDO UAF credentials of biometric and fingerprint authenticators when the user adds new biometric credentials in the OS settings, see invalidateOnNewOsBiometrics (NEVISACCESSAPP-4655).
  • NEW: We now support providing HTTP request headers that can be sent in the HTTP request during all the operations, see requestHeaders (NEVISACCESSAPP-4722).
  • FIXED: After successful authentication, if a cookie is provided by the backend and it contains a domain, the URI of the Cookie in the returned CookieAuthorizationProvider will refer to that domain. If the cookie contains a path, the URI of the Cookie will also contain the path (NEVISACCESSAPP-4671).
  • CHANGED: The release flavor of the SDK removes SDK data when a guard fails (NEVISACCESSAPP-4749).
  • NEW: The new method LocalData.deleteAuthenticator(username) allows to remove all the authentication data associated with a user in a single call (NEVISACCESSAPP-4796).
  • FIXED: The username attribute is no longer included in the registration FIDO response sent to the server (NEVISACCESSAPP-4925).
  • FIXED: The error consumer of the registration operation is invoked only once when the operation times out (NEVISACCESSAPP-4922).

For more information, see API references.

Android SDK 3.2.2 - 15.05.2023​

  • UPDATE: The hardening framework has been upgraded to the latest version (NEVISACCESSAPP-4831).

Android SDK 3.2.1 - 30.03.2023​

  • CHANGED: The hardening code is executed in parallel. This will improve SDK initialisation speed measurably on slower devices (NEVISACCESSAPP-4716).
  • FIXED: the registrationConsumer and authenticationConsumer provided to the OutOfBandOperation are now invoked from the UI thread (NEVISACCESSAPP-4738).

For more information, see API references.

Android SDK 3.2.0 - 26.03.2023​

For more information, see API references.

Android SDK 3.1.1 - 01.03.2023​

General changes and new features​

  • FIXED: We fixed the bug where, if cookie renewal was configured in the backend, deregistration providing the authenticator AAID did not delete device information in the server (NEVISACCESSAPP-4574).

For more information, see API references.

Android SDK 3.1.0 - 26.02.2023​

General changes and new features​

  • NEW: We now support class 2 sensors for the biometric authenticator, see allowClass2Sensors.
  • CHANGED: LocalData.deleteAuthenticator does not throw an IllegalArgumentException if the username and AAID are not registered. This aligns the Android behavior with its iOS counterpart.
  • CHANGED: From this version on, the deregistration operation does not require the aaid to be provided. Providing no aaid in the operation leads to the whole account being deregistered instead of a single authenticator (NEVISACCESSAPP-4432)

For more information, see API references.

Android SDK 3.0.0 - 27.09.2022​

Dear Nevis customers, we are proud to present you with a new major Nevis Mobile Authentication SDK release.

Why​

The previous 2.x versions of the Android and iOS SDKs where created with the main goal of providing mobile authentication capabilities for native apps.

Although the two platform SDKs share similar features, concepts, flows and terminologies, they adhere to their respective platform engineering best practices and are not congruent. Because of this, cross-platform frameworks and plugins require a lot of effort to handle the platform differences to align the two SDKs.

Our Nevis Mobile Engineering team identified the cross-platform integration difficulties some time ago. As we are facing more customer requests asking specifically for cross-platform integration, our engineering team started designing this major SDK version 3.x specifically for achieving the goal of providing easier cross-platform integration.

This new SDK version addresses additional customer requests as well as coming with improvements in several areas:

  • Improved and aligned SDK documentation: One documentation for all platforms. The Nevis Mobile Engineering team completely overhauled the SDK documentation which lead to it being unified for all supported platforms, providing platform specific code snippets and additional information
  • Better Nevis Authentication Cloud integration: As we expect more SDK customers for the Nevis Authentication Cloud, we provide easier and better integration specifically for this backend. In addition, we have specific chapters in our documentation addressing Authentication Cloud integration scenarios with additional examples.
  • Aligned example apps with source code: As our customer repeatedly requested example apps, we are listening to them. We are providing example apps for all supported platforms with the goal of giving SDK customers / developers the quickest way of having compilable and directly usable examples. All example apps are aligned, using the same UI to serve recognition value. In addition, we are making the source code available directly through git repository.

Contents of the initial 3.0 SDK release​

The initial 3.0 SDK release contains:

  • The native platform SDKs for Android and iOS
  • The improved and aligned SDK documentation
info

The example applications are not yet available with the initial 3.0 SDK release.

General changes and new features​

  • NEW: Introduced a new API, which is unified across all supported platforms (NEVISACCESSAPP-4234).
    • With this, the old API becomes no longer publicly available, thus enclosing applications need to be migrated to the new API. For more information, see Migration Guide.

For more information, see API references.

Android SDK 2.4.2 - 21.06.2023​

See the SDK Upgrade Guide when migrating from a previous SDK version.

General changes and new features​

  • FIXED: We fixed the bug where writing the dispatch target keys in parallel could corrupt the file (NEVISACCESSAPP-4943).

Android SDK 2.4.1 - 12.04.2023​

See the SDK Upgrade Guide when migrating from a previous SDK version.

General changes and new features​

  • UPDATE: The hardening framework has been upgraded to the latest version (NEVISACCESSAPP-4689).

Android SDK 2.4.0 - 02.08.2022​

See the SDK Upgrade Guide when migrating from a previous SDK version.

General changes and new features​

  • NEW: It is now allowed to decrypt the NmaData in the new CryptoUtils interface (NEVISACCESSAPP-3786).
  • FIXED: We fixed the bug where the SDK crashed during registration after LocalData.deleteAllData() was invoked (NEVISACCESSAPP-4025).
  • FIXED: We fixed the bug where the biometric and fingerprint authenticators could not be registered when using a Xiaomi phone with a working profile (NEVISACCESSAPP-4131).
  • UPDATE: The hardening framework has been upgraded to the latest version (NEVISACCESSAPP-4090).

Android SDK 2.3.2 - 15.06.2022​

General changes and new features​

  • FIXED: The DeregistrationServiceDelegate methods are now invoked from the UI thread.

Android SDK 2.3.1 - 04.05.2022​

General changes and new features​

  • FIXED: The hardening framework has been upgraded to the latest version. Root Detection now detects the Fox Magisk Module Manager application (NEVISACCESSAPP-3809).
  • FIXED: nevisAuth session retrieval was broken. After successful authentication, no CookieAuthorizationProvider was returned by the SDK. The issue is now fixed (NEVISACCESSAPP-3860).
  • FIXED: Secondary authenticator registration on Android was not correlated with a physical device. The SDK now sends a device ID attribute when a dispatch target is defined (NEVISACCESSAPP-3809).

Android SDK 2.3.0 - 28.03.2022​

General changes and new features​

  • FIXED: SDK returns error when FidoUafOperations.deregisterAll is invoked with no defined dispatch target (NEVISACCESSAPP-3731).
  • FIXED: SDK removes FIDO UAF credentials of other devices when FidoUafOperations.deregister is invoked (NEVISACCESSAPP-3728).
  • CHANGED: We no longer return an error for deregistration when invoking FidoUafOperations.deregisterAll and FidoUafOperations.deregister if no authenticators are registered. This aligns the behavior of both iOS and Android SDKs (NEVISACCESSAPP-3724).

Android SDK 2.2.1 - 23.03.2022​

Hotfix Release

This is a hotfix release addressing an issue leading to data and credential removal on Samsung devices.

Samsung devices wrongly report the absence of secure hardware if a key store is created using a flag indicating the key store purpose as signing. This onlyoccurs on Samsung devices, all other tested Android platforms do not expose this behavior.

General changes and new features​

  • FIXED: User data on some Samsung devices is no longer removed because the SDK did not detect a TEE (NEVISACCESSAPP-3771).

Android SDK 2.2.0 - 18.02.2022​

Decomissioned - DO NOT USE

This release is considered decommissioned as it contains a severe bug leading to credential data deletion on Samsung devices.

Samsung devices wrongly report the absence of secure hardware if a key store is created using a flag indicating the key stores purpose as "signing". This only occurs on Samsung devices, all other tested Android platforms do not expose this behaviour.

The SDK 2.2.1 hotfix fixes this issue.

The 2.2.0 SDK API is compatible with the last SDK version, but the introduction of the new biometric authenticator may break existing applications. For more information, see the update guide.

General changes and new features​

  • NEW: A new biometric authenticator is introduced (NEVISACCESSAPP-3431).
  • CHANGED: We increased the number of PBKDF2 iterations used to calculate hashes. With this change, more powerful hardware devices use higher iteration counts than low-power devices (NEVISACCESSAPP-3555).
  • FIXED: You can now use the finalizer plugin to build the application as a bundle which is *unsigned.* (NEVISACCESSAPP-3614).
  • CHANGED: From now on, FIDO UAF credentials for fingerprint and biometric require user authentication at the operating system level (NEVISACCESSAPP-3605).
  • UPGRADED: The hardening framework has been upgraded to the latest version (NEVISACCESSAPP-3618).
  • FIXED: We fixed a NullPointerException, which occurred when OsAuthenticationListenHandler.cancelAuthentication() was invoked after OsAuthenticationListenHandler.pauseListening() (NEVISACCESSAPP-3647).

Android SDK 2.1.1 - 04.01.2022​

The 2.1.1 SDK API is compatible with the last SDK version, migration is not required.

General changes and new features​

  • FIXED: When using multiple accounts, the SDK does not delete existing authentication methods if a registration fails or is canceled.

Known Issues and Mitigations​

Using the current finalizer plugin shipped with the 2.1.1 SDK, it is not possible to build your application as a bundle which is *unsigned*.This is not required or needed for most SDK integrations where developers wish to publish their already signed applications. We expect this to be solved in a future release with an improved version of the hardening framework provided by our supplier. If you attempt to create a bundle with a null signing configuration, the build crashes with a null pointer exception.

If you wish to create an unsigned app bundle, and sign it later or delegate the signing to a third party - the following steps need to be taken to ensure a successful build:

  1. Ensure that the finalizer is included in your build.gradle files, and the plugin is applied as indicated in the Reference Guide.
  2. Ensure that the build type, or product flavor and build type you wish to create references a signing configuration. While initially this appears counterintuitive, this step is necessary to mitigate the issue. The signing configuration has to be valid such that it is possible for gradle to run the command to build a signed bundle - ./gradlew bundleRelease, for example.
  3. Once the signed bundle is created, examine the app build output directory: {project root}/app/build/fin/{build and product flavor combination}. In this directory, you find {app name}-unsigned-unaligned-protected.aab. This is the correct unsigned bundle, and can be signed using the Android Bundle Tool. See Signing your app from the command line.

Android SDK 2.1.0 - 23.11.2021​

The 2.1.0 SDK API is compatible with the last SDK version, migration is not required.

General changes and new features​

  • NEW: Multiple accounts are supported.
  • NEW: API 31 (Android 12) is supported.
  • NEW: We added the new method pauseListening to the OsAuthenticationListenHandler interface to avoid errors when application is sent to the background.
  • NEW: From now on, the transaction confirmation data is provided in the AuthenticatorSelectionConsumer interface. It is recommended to present the transaction confirmation to the user before the authenticator selection.
  • NEW: OpenJDK 11 is supported.
  • NEW: Gradle Android Plugin 3.2 to 7.0.2 is supported.
  • NEW: You can now provide facet ID in SdkConfiguration.
  • NEW: The maximum time that the SDK waits for user input during user interaction can be configured using SdkConfiguration.userInteractionTimeout method.
  • NEW: The SDK exposes the dispatch target IDs associated with each account.
  • CHANGED: The debug flavor of the SDK does not check whether the device lock is enabled. This allows to perform automatic testing with virtual devices that do not have a device lock.
  • CHANGED: The UserVerificationMethod interface is removed from the API as it was not referenced by any other SDK API either.
  • FIXED: The SDK checks if the dispatch target is defined in the server before discarding the DispatchTarget object provided during registration. This fix prevents the edge case where the backend-side credentials for the FIDO UAF authenticators and dispatch target are removed, and the user (without noticing it) registers a new authentication method. Without the fix, the user could not use the newly registered authentication method for out-of-band scenarios as the device could not receive push notifications, and authentication payloads could not be encrypted.

Known Issues and Mitigations​

Using the current finalizer plugin shipped with the 2.1.0 SDK, it is not possible to build your application as a bundle which is *unsigned*.This is not required or needed for most SDK integrations where developers wish to publish their already signed applications. We expect this to be solved in a future release with an improved version of the hardening framework provided by our supplier. If you attempt to create a bundle with a null signing configuration, the build crashes with a null pointer exception.

If you wish to create an unsigned app bundle, and sign it later or delegate the signing to a third party - the following steps need to be taken to ensure a successful build:

  1. Ensure that the finalizer is included in your build.gradle files, and the plugin is applied as indicated in the Reference Guide.
  2. Ensure that the build type, or product flavor and build type you wish to create references a signing configuration. While initially this appears counterintuitive, this step is necessary to mitigate the issue. The signing configuration has to be valid such that it is possible for gradle to run the command to build a signed bundle - ./gradlew bundleRelease, for example.
  3. Once the signed bundle is created, examine the app build output directory: {project root}/app/build/fin/{build and product flavor combination}. In this directory, you find {app name}-unsigned-unaligned-protected.aab. This is the correct unsigned bundle, and can be signed using the Android Bundle Tool. Refer to the section Signing your app from the command line in `http://developer.android.com/studio/build/building-cmdline.

Android SDK 1.8.0 - 16.06.2021​

See the SDK Upgrade Guide when migrating from a previous SDK version.

General changes and new features​

  • NEW: The SDK now exposes the objects PinCredentialFormat and CredentialFormat in the API. This allows the app to perform validation on the PIN screens.
  • CHANGED/FIXED: The UserInteractionDelegate.onValidCredentialsProvided is now invoked from the main thread.
  • CHANGED/FIXED: The methods onOperationSucceeded and onOperationFailed of the service delegates of the SDK are now guaranteed to be invoked from the main thread.
  • CHANGED/FIXED: The methods Delete Dispatch Target and Update Dispatch Target are now executed asynchronously.
  • CHANGED/FIXED: The authenticators are now ordered consistently in the Set returned by the LocalDataManager and the context interfaces of the user interaction delegation.
  • FIXED: When registration failed, the system did not clean up the corresponding data. This bug is now fixed.
  • FIXED: The SDK sent an additional request when the FIDO server returned an error. This bug is now fixed.
  • FIXED: The fingerprint authenticator did not return an authentication error in some devices after it was temporarily locked. This bug is now fixed.
  • FIXED: The SDK kept listening for credentials after a recoverable error. This bug is now fixed.
  • UPGRADED: The hardening framework has been upgraded to the latest version.

Android SDK 1.7.0 - 15.02.2021​

See the SDK Upgrade Guide when migrating from a previous SDK version.

General changes and new features​

  • NEW: Major improvements and changes in the user interaction API.

This is a breaking change. Refer to the SDK Upgrade Guide for instructions on migration. Do not hesitate to contact Nevis if there are questions and uncertainties.

  • NEW: New exceptions to help identifying network and authenticator level errors are now available.
  • NEW: Support is now available for JWT-based authentication is only supported on Nevis Authentication Cloud instances. For more information, see the Nevis Mobile Authentication Concept and Integration Guide.
  • NEW: The SDK now adds a custom User-Agent header on its request to identify the OS and devices used.
  • NEW: The SDK now allows specifying the network timeouts to be used when executing HTTP requests.
  • CHANGED: The SDK now throws a FidoUafException with the message ErrorCode.USER_CANCELLED when an operation is cancelled during user interaction.
  • CHANGED: The HTTP Authentication Interceptor now detects headers in a case-insensitive way.
  • CHANGED: AuthenticationServiceDelegate.onActionSuccess is now only invoked once after a successful authentication.
  • CHANGED: As of this release, the SDK only presents authenticators that are supported by the device.
  • FIXED: The Fingerprint workflow as well as deadlocks and crashes when using the fingerprint authenticator are improved and/or fixed.
  • FIXED: The PIN brute force attack prevention workflow is fixed.
  • FIXED: The bug where modifying the Fingerprint configuration in the OS settings would invalidate the FIDO UAF credentials associated with the fingerprint authenticator.
  • FIXED: The bug where providing an empty PIN caused the SDK to crash.
  • PERFORMANCE: The build time of hardened builds are been decreased.

Android SDK 1.3.4 - 19.01.2021​

See the SDK Update Guide when migrating from a previous SDK version.

No additional steps need to be taken to upgrade from 1.3.3 to 1.3.4, however any steps to upgrade from previous versions to 1.3.3 are still valid.

General changes and new features​

  • FIXED: Improved handling of recoverable errors when using less accurate fingerprint sensors on certain Android devices.
  • FIXED: Fingerprint detection is resumed correctly after switching between the apps on the device and returning to the SDK integrated app.

Known Limitations​

Using Maven repositories to publish the finalization plugin JAR is problematic because its name must be guardit4j-finalize.jar.

Android SDK 1.3.3 - 07.07.2020​

See the SDK Update Guide when migrating from a previous SDK version.

The steps in the 1.3.2 Upgrade Guide need to be implemented in addition to the 1.3.3 steps.

General changes and new features​

  • NEW: The Android Gradle plugin now supports all versions from 3.2 to 4.0.
  • FIXED: The potential multidex limit occuring during app finalization is fixed.

Breaking Change

apply plugin: 'guardit4j-finalize'

See the Installation section of the Concept and Integration Guide of the Android SDK for more details.

  • PERFORMANCE: The build time during app finalization is improved significantly.

Known Limitations​

Using Maven repositories to publish the finalization plugin JAR is problematic because its name must be guardit4j-finalize.jar.

Android SDK 1.3.2 - 06.07.2020​

Version 1.3.2 is not recommended for production purposes. The steps in the 1.3.2 Upgrade Guide need to be implemented when upgrading to higher versions.

See the SDK Update Guide when migrating from a previous SDK version

Android SDK 1.3.1 - 13.05.2020​

See the SDK Update Guide when migrating from a previous SDK version

General changes and new features​

  • NEW:The SDK enforces a minimal pin length of 6 digits.
  • NEW: The SDK protects the PIN authenticator from brute force attacks, for details see the [security considerations chapter].
  • CHANGED: The check for the FIDO authentication realm provided in the WWW-Authenticate header is loosened. The SDK now only verifies the presence of the string FIDO realm during a FIDO-based authentication.
  • FIXED: Theslow SDK initialization issue because of waiting for the firebase push token to be available is fixed.
  • FIXED: The user cancellation propagation issue is fixed. The SDK now propagates user cancellation actions to the backend. See the SDK chapter "Error Handling" for details.

Android SDK 1.3.0 - 20.11.2019​

General changes and new features​

  • NEW: Initial release. The supported mobile authentication use cases involve the following FIDO UAF 1.1 operations: The Nevis Mobile Authentication Client SDK for Android supports the following authenticators:

Known Limitations​

PIN Authenticator Limitations​

The PIN Authenticator shipped with the Nevis Mobile Authentication SDK for Android released in this version contains known limitations. This section describes the limitations, their consequences and possible mitigation which can be undertaken from the custom app implementation.

LimitationDescriptionMitigation
No enforcement of minimal PIN lengthThe current SDK does not enforce a minimal PIN length when defining the PIN used by the Authenticator. It is technically possible to define a PIN with one digit only which of course is easily guessable. The next SDK release will enforce a minimal PIN length of 6 digits.It is recommended to enforce a minimal PIN length in the app using the SDK by implementing a verification in every scenario the user is setting or changing the PIN.This helps reducing the issue of using an insecure PIN for the PIN Authenticator. Furthermore, it is recommended to protect the respective source code with anti-tamper guards to ensure malicious users are unable to inject shorter PINs between the custom app and the SDK.
No brute force attack prevention for the PIN authenticatorThe PIN Authenticator shipped with the Android SDK is not resilient against brute force attacks. A user can enter a wrong PIN indefinitely without any consequences. By automating the PIN entry an attacker is potentially able to brute-force the PIN in a short amount of time if he has access to the users device. The next SDK release will protect the PIN Authenticator against brute force attacks as it is already the case for the iOS PIN Authenticator and outlined in the Security Considerations chapter of the Nevis Mobile Authentication Client SDK Guide.It is recommended to protect the PIN Authenticator against brute force attacks by introducing cool-down periods upon wrong PIN entries. Multiple wrong PIN entry attempts lead to an increase in the cool-down time and finally to the direct removal of the PIN Authenticator and its associated credentials on the mobile phone. The SDK currently does not report the root cause of the operation failure, the app itself must track the number of failed attempts based on the erroneous operation and must block access to the user on too many failed attempts.
Last updated on