Security considerations

Assumptions

The Nevis Mobile Authentication SDK relies heavily on the security components provided by the manufacturer of the device. The SDK assumes that these components are secure and therefore delegates the responsibility to the manufacturer.

The specific security components relied upon are as follows:

Platform	Security Element
all	Device Screen Lock
all	Secure Storage of the biometric data
all	Verification of biometric data is executed in the Trusted Execution Environment (TEE)
all	Biometric Sensors
Android	Android Keystore System
iOS	Keychain
iOS	Secure Enclave

info

Despite the reliance on the security components of the device and OS manufacturers, the SDK is hardened to further mitigate security risks and lower attack scenarios originating from the mobile application or the SDK. For more information, see the SDK hardening and flavors section.

The following security considerations are important to understand the impact they have on private key protection. For more information on private key protection, see the Key Protection chapter.

Communication

TLS/HTTPS

Requirements

To ensure secure end-to-end transit of data between the Nevis Mobile Authentication SDK and the Nevis Mobile Authentication backend, both must be configured to use TLS. The SDK is configured to use only TLS connections and any calls to the backend without TLS fails.

Apple-Trusted Certificate Requirements

Note that Apple has strict requirements regarding trusted TLS certificates that are imposed since iOS 13. You need to ensure that the public-facing certificates match these requirements or the connection between the iOS app using the SDK and the backend fails.

Self-signed certificates

The Nevis Mobile Authentication Solution does not support using self-signed certificates for the TLS connection. There is however a possibility to use self-signed certificates by trusting them in the OS settings.

Ciphers

iOS

The iOS SDK uses URLSession for all HTTPS connections.

Taken from the official documentation:

App Transport Security provides default connection requirements so that apps adhere to best practices for secure connections when using NSURLConnection, CFURL, or NSURLSession APIs. By default, App Transport Security limits cipher selection to include only suites that provide forward secrecy, specifically: ECDHE_ECDSA_AES and ECDHE_RSA_AES in Galois/Counter Mode (GCM), Cipher Block Chaining (CBC) mode.

Android

The Android SDK uses a third party library for HTTPS connections. The SDK limits the supported ciphers to the following list considered to be secure and best practice:

Android Ciphers

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384

Authorization handling

Authorization headers such as Cookies or JWT tokens returned by the SDK after a successful authentication are not cached by the SDK in any way. The SDK directly parses and returns the HTTP authorization headers. In addition the iOS SDK returns the authorization cookies from ephemeral url session in case no cookie was returned in HTTP headers.

Push encryption

Push notifications are one way that the Nevis Mobile Authentication backend uses to communicate with the mobile application. To ensure confidentiality, push notification content is sent end-to-end encrypted to the mobile applications. The Javascript Object Signing and Encryption (JOSE) framework is used for this purpose. The SDK generates the necessary asymmetric key material, and securely stores it on the device. To establish the encrypted communication channel, the public key can be sent to the backend when registering the registration token.

Encrypting push notification content eliminates the following main security concern: If an attacker reads an unencrypted push notification, they could potentially extract the tokens required to retrieve the plaintext of the transaction text in out-of-band transaction confirmation operations. But they will not be able to confirm the transaction, since explicit user verification is required.

info

Further information regarding push notification encryption can be found in the Out-of-band message transmission chapter of the nevisFIDO documentation.

SDK hardening

The Nevis Mobile Authentication SDK uses a professional hardening and attack prevention product to harden the Android and iOS SDKs.

In a typical attack scenario, an attacker roots/jailbreaks the mobile device to bypass the built-in security of the device. On such devices, the attacker is able to access and modify almost anything stored in the operating system of the device. For this reason, the SDK performs various checks to inspect the integrity of the system. Furthermore, the SDK is extensively obfuscated and protected against tampering and reverse engineering. It detects any attempt at modifying normal execution of the operations.

When any kind of threat is detected, the SDK prevents normal application execution following one of these patterns:

• Crashing the app.
• Stopping responses to any operations.
• Throwing an exception.

These measures ensure that all of the authenticators protecting the private key are robust against the most wide-spread attacks originating from the mobile application or the SDK itself.

Application obfuscation and hardening

It is generally recommended to perform a minimal obfuscation on any kind of application, no matter what the intended use case or target security level is.

The SDK provides some indirect enhanced security for the integrating app. However, the SDK does not take care of sensitive information generated by the application, which goes beyond the scope of the SDK use cases. For such high security applications, it is recommended that they also use application level hardening to manage sensitive data.

Pay attention to the following recommendations in case application level obfuscation or hardening are intended:

• Ensure that no obfuscation or hardening takes place for any SDK internals or exposed interfaces (clear separation between application code and SDK).
• Specifically for hardening, use products from the same vendor as the Nevis Mobile Authentication Client SDK, inquire us for more information.

caution

The use of other hardening frameworks is only supported on a best-effort basis. We strongly recommend using products from the same vendor. Nevis cannot guarantee successful hardening of the application layer with other frameworks in any scenario.

SDK flavors

To satisfy customers with the highest security requirements, the Nevis Mobile Authentication SDK is hardened with state-of-the-art protection mechanisms. Due to the restrictive protection mechanisms, the SDK is available in two build flavors:

• debug is used during the development phase of the mobile application where only a subset of the protection mechanisms are available. Using debug, the application can be run in a simulator or emulator environment. debug is intended for testing use, and is not to be used in a production environment.
• release is used in production, where all protection mechanisms are activated. The release flavor requires your application to be finalized.

danger

It is prohibited to use the debug flavor in production environments (e.g. app builds shipped to end users via app stores)!

Disabled tamper guards in the debug flavor

The following specific guards are not present in the debug flavor:

Android:

• Emulator detection
• Debugger detection
• Root detection
• Checksum
• Hook detection
• Dynamic instrumentation detection

iOS:

• Debugger detection
• Simulator detection (Dynamic instrumentation detection)

Tamper Detection

SDK hardening includes extensive measures to detect tampering by malicious parties. Tampering is unauthorized modification of software code. Typically, people tamper with software for the following reasons:

• To gain unauthorized access to a program
• To modify code or inject malware
• To reverse engineer a program and lift code or other intellectual property

Attackers typically tamper with a compiled application and have no access to the original source code. They must find ways to understand the compiled program, locate its vulnerabilities, and modify the binary.

Runtime tamper actions are triggered by various manipulation attempts such as:

• Jailbreaking/rooting devices
• Attaching debuggers
• Bypassing of security-relevant code
• Manipulating code

In these scenarios, the SDK will cause the app to crash by triggering a non-recoverable exception.

The hardening framework defends against tampering by applying a set of protection techniques to source code. The units of code that implement these techniques are called Guards.

info

The exception itself is obfuscated and prevents drawing conclusions regarding the root cause of the app crash. The application using the SDK is unable to react or prevent the app crash in any way. This is intentional, crashing the application fast mitigates the risk of exposing any sensitive information to a possible attacker.

Apart from runtime tamper actions, the SDK is protected against reverse engineering using obfuscation and breaching the binary integrity of the archive.

Tamper guards

The following guards are used to protect the Nevis Mobile Authentication SDK. Be aware that this is not a complete list, it focuses on the most important guards in use.

Many of the guards listed in the table are used more than once and in several areas of the code. Additionally, they are protected themselves by a guard network.

Root detection

Root detection guards detect whether the mobile device, on which the application is running is modified to allow users or applications privileged access to the operating system. This guard is only available on the Android platform.

Jailbreak detection

A Jailbreak Detection guard detects that an application is running on a jailbroken device. An application running on a jail-broken device is more vulnerable to attacks. This guard is only available on the iOS platform.

Debugger detection

A debugger detection guard executes an algorithm to detect whether a debugger is attached to the application.

Hook detection

Hooking attacks can change the behavior of the app by redirecting a method call to an attacker’s method, or by replacing or modifying an app resource. Hook detection guards can detect such attacks by checking for the following:

• On the device, the presence of hook software–software that is capable of hooking methods.
• Hooked methods in the protected app.
• Replaced app resources.
• The presence of apps that require the hook software to be present

Emulator detection

Detects whether the application is running in an emulator.

Dynamic instrumentation detection

The Dynamic Instrumentation Detection guard detects the presence of the following frameworks:

• Frida - A dynamic instrumentation toolkit that allows its users to deconstruct and reverse engineer Android Apps. This guard can detect even when Frida is using non-default settings, or when Frida is not actively instrumenting the protected application
• GameGuardian - An app that allows its users to hack and cheat in Android games.

Checksum

A Checksum guard detects whether any code within DEX files is modified by computing a checksum of the code when protection is applied and then computing the checksum again at runtime.

Renaming

The renaming guard replaces the names of packages, classes, methods, and fields with unintelligible symbols. An attacker attempting to reverse engineer a protected program, will see meaningless names. If the attacker succeeds in decompiling the bytecode (.class files), the attacker will also see meaningless names in the decompiled source code (.java files).

String encryption

A string encryption guard encrypts all literal strings in the target input files. String encryption protects against static and dynamic analysis and reverse engineering. String decryption is performed at runtime, when the strings are used.

Debug Info

Removes contextual debugging information from Java class files.

Control flow

The control flow obfuscation guard scrambles Java bytecode, making it difficult for an attacker who succeeds in decompiling or disassembling the protected program to understand its control flow. Because obfuscation does not affect the semantics of the program, the protected program has the same functionality as the original.

SDK updates

It is the responsibility of Nevis Mobile Authentication SDK consumers to decide how and when to update the Nevis Mobile Authentication SDK. To include the latest security fixes, we strongly recommend that you upgrade to the latest versions of the Mobile Authentication SDK on a regular basis.

A common approach to update mobile applications, and therefore the libraries used by them too, is to create an update service hosted on a backend. The application contacts the service to determine whether the app itself needs to be updated, regardless of the SDK version. The decision to update the SDK, or any other dependency, is made by developers during implementation.

info

The nevisFIDO backend provides a service endpoint of this type that can be used to implement this functionality in a custom mobile application.

Device loss

Mobile authentication provides two-factor authentication based on possession of the device, and an authentication mechanism such as a PIN or biometrics. This means that losing the device compromises one of the factors, that is, possession of the device. Therefore, users should be requested to report device loss, so that the device and its associated credentials can be disabled for authentication. We recommend implementing one of the following methods to disable the lost device for authentication:

• Provide a self-service restricted to removing registered devices and credentials after authenticating with an alternate authentication method or through an identity verification service.
• Provide a support hotline where users can report the loss of their device. After manual authentication of the user, the device and associated credentials can be removed by the support desk agent.

Device lock removal

The authenticator private key is a highly sensitive protective asset that is securely stored in hardware. Hardware storage is only possible if the device is protected with a device lock screen.

caution

If the device lock screen is removed, even temporarily, the keys stored in the hardware-backed Keystore or Secure Enclave are wiped by the operating system of the device.

info

The Android SDK does not enforce device lock presence in the debug flavor, this is to ease automated testing. The release flavor enforces the presence and throws a specific error if the device lock is not present.

There might also be other situations in which the operating system of the device decides to wipe the content of the hardware-backed Keystore or Secure Enclave. On newer devices and newer device OSes, adding an additional fingerprint might also wipe the keys. In any case, the Nevis Mobile Authentication SDK returns an error. The mobile application must handle this case correctly, and ask the user to go through a new registration process.

Compromise of OS

The private key stored in the Android Keystore System or Secure Enclave is well protected from extraction, since it is stored in hardware. However, a residual risk remains: The OS controls who is allowed to use the key and how. This implies that in the case of a compromised (that is, rooted or jailbroken) device, it is not possible to prevent an attacker from using the private keys for their own purposes. To reduce the risks of attacks originating from inside the Nevis Mobile Authentication SDK, several hardening measures are in place. They prevent use of the SDK if the device is compromised.

It is the responsibility of the manufacturer to ensure the security of these security elements. For more details about the responsibility of the manufacturer, see Security assumptions.

caution

Nevis is not responsible for any consequences if the user installs the app on a rooted device.

Missing TEE for secure storage of key material

The SDK enforces the presence of a TEE module for securely storing the key material. If no such TEE is present, the SDK cannot execute any operation.

FIDO

The following chapters are directly related to the FIDO UAF protocol and specification.

FIDO UAF specification-related security considerations

This section lists and explains the Nevis Mobile Authentication answers and solutions to the chapter FIDO UAF Security Considerations in the official FIDO specification. The chapters and solutions referred to here require no direct action when using the component. They simply state the solutions of Nevis Mobile Authentication (if applicable) for the security considerations posed by the protocol specification.

4.3.1 Authenticator Security

Scope: Client

The SDK implementation follows access control for commands outlined by the FIDO UAF 1.1 specification. Explicit user verification is required for the registration and authentication operations.

4.3.2 Cryptographic Algorithms

Scope: Client and Server

Authenticator	AAID	Authentication Algorithm	Public Key Representation Format
Android PIN Authenticator	F1D0#0001	ALG_SIGN_RSA_EMSA_PKCS1_SHA256_DER	ALG_KEY_ECC_X962_RAW
Android Fingerprint Authenticator	F1D0#0002	ALG_SIGN_RSA_EMSA_PKCS1_SHA256_DER	ALG_KEY_ECC_X962_RAW
Android Biometric Authenticator	F1D0#0003	ALG_SIGN_RSA_EMSA_PKCS1_SHA256_DER	ALG_KEY_ECC_X962_RAW
Android Device Passcode Authenticator	F1D0#0004	ALG_SIGN_RSA_EMSA_PKCS1_SHA256_DER	ALG_KEY_ECC_X962_RAW
iOS PIN Authenticator	F1D0#1001	ALG_SIGN_SECP256R1_ECDSA_SHA256_DER	ALG_KEY_ECC_X962_DER
iOS Touch ID Authenticator	F1D0#1002	ALG_SIGN_SECP256R1_ECDSA_SHA256_DER	ALG_KEY_ECC_X962_DER
iOS Face ID Authenticator	F1D0#1003	ALG_SIGN_SECP256R1_ECDSA_SHA256_DER	ALG_KEY_ECC_X962_DER
iOS Device Passcode Authenticator	F1D0#1004	ALG_SIGN_SECP256R1_ECDSA_SHA256_DER	ALG_KEY_ECC_X962_DER

4.3.3 FIDO Client Trust Model

Scope: Client

The SDK implementation follows the trust model outlined by the FIDO UAF 1.1 specification.

To prevent access to protected data, several measures are in place such as:

• Usage and enforcement of TEE
• Tamper detection through SDK hardening

4.3.4 TLS Binding

Scope: Client

Not applicable - must be solved on the FIDO client-side. The client is responsible for server certificate validation.

4.3.5 Session Management

Scope: Client and Server

Client-side sessions are managed with cookies as outlined in the HTTP API authentication chapter.

4.3.6 Persona

Scope: Client and Server

The Nevis Mobile Authentication SDK does not support the concept of personas.

4.3.7 ServerData and KeyHandle

Scope: Server

Not applicable - must be solved on the FIDO server-side.

4.3.8 UAF Application API

Scope: Server

Not applicable - must be solved on the FIDO server-side.

4.3.9 Policy Verification

Scope: Server

Not applicable - must be solved on the FIDO server-side.

4.3.10 Replay Attack Protection

Scope: Server

Not applicable - must be solved on the FIDO server-side.

4.3.11 Cloned Authenticators

Scope: Server and Client

The SDK is resilient against cloning authenticators by storing the relevant key material in TEE that cannot be extracted. For more information, see the Secure Storage chapter.

4.3.12 Anti-Fraud-Signals

Scope: Server and Client

The anti-fraud signals outlined by the FIDO UAF specification are not supported by the SDK.

Specifically, the Sign counter and Reg counter are not implemented and as a result always provide the 0 value, as outlined by the specification.

Authenticator attestation

In the FIDO UAF 1.1 context, authenticator attestation ensures that only trusted authenticators can be used to authenticate with a relying party.

To achieve reliable authenticator attestation, an attestation private key can be embedded into a FIDO UAF authenticator during the manufacturing process. This key is the same for all authenticators of a certain type. This means that the attestation private key is bound to a specific authenticator class and not to a specific authenticator itself. Through verification of a signature provided by the authenticator, the server-side can validate whether it is really communicating with the type of authenticator that the client is claiming to use.

info

Since the FIDO UAF authenticators that are shipped with the Nevis Mobile Authentication SDK are software-based, they do not provide sufficient protection for attestation private keys (non-attested authenticators). This means that the attestation method used by the provided FIDO UAF authenticators is called Surrogate Basic Attestation.

Authenticator Security Properties

Up to three different authentication methods can be integrated into the mobile application. You can choose between:

• Application PIN authentication (Android and iOS)
• Device Passcode authentication (Android and iOS)
• Fingerprint authentication (Android)
• Face authentication (Android)
• Touch ID authentication (iOS)
• Face ID authentication (iOS)

All apart from application PIN and device passcode are referred to as biometric authentication methods.

The authenticator private key is a highly sensitive asset to protect. To enable as much protection as possible, the asymmetric key pairs are stored in a hardware-backed keystore. For iOS, the key is stored in the Secure Enclave. For Android, the private key is stored in the Android Keystore system.

Where the authentication methods differ, is how they access the key:

• The biometric authentication methods require users to provide biometric information. If there is a match, then the private key is unlocked to carry out the cryptographic operations.
• The device passcode authentication methods require users to provide PIN, password or gesture (depending how the device lock is configured in the operating system settings). If there is a match, then the private key is unlocked to carry out the cryptographic operations.
• The Application PIN authentication requires users 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 relating to security is where the matching occurs:

• Application PIN authentication matching takes place in the Nevis Mobile Authentication SDK itself.
• Biometric and device passcode authentication matching is carried out by the operating system itself.

Android - additional credential protection

As an additional security layer in Android, the FIDO UAF credentials for biometric, device passcode and fingerprint authenticators are protected by the OS requiring user authentication.

Xiaomi Android devices and work Profiles

When running in a work profile and using a Xiaomi phone, the FIDO UAF credentials are not protected through user authentication. This is required because Xiaomi phones do not separate credentials across profiles, and user authentication does not work when running on the work profile.

Biometric Authenticator Invalidation on New OS Biometrics

Setting true in the Registration.invalidateOnNewOsBiometrics _{java, swift, objc, flutter, react native} method will invalidate the biometric and fingerprint authenticators when the user adds new biometric credentials in the OS settings. This will increase the security, because an attacker with access to the device passcode can add biometric credentials and authenticate with your application otherwise.

Invalidating authenticators introduces a loss of convenience for end users: adding a new OS biometric credential does not imply necessarily that there is a security risk, but if the end-user adds it, a new registration will be required, because an invalidated authenticator cannot be recovered.

If you do not want to allow using the device passcode as fallback for the biometric authenticator (see Registration.allowDevicePasscodeAsFallback_{java, swift, objc, flutter, react native}), we recommend invalidating the authenticator if new biometric credentials are added in the OS settings.

caution

We have observed that when using Pixel 4a and Pixel 5 devices, the authenticator is also invalidated if the user removes biometric credentials in the OS settings, and there are still biometric credentials defined. See this bug for details.

PIN authentication

PIN authentication method

The Application PIN authenticator is less secure than biometric and devide passcode authentication. This is based on the following factors:

The access mechanism of the PIN authenticator private key does not require biometric unlocking. As opposed to biometric and device passcode authentication methods, PIN verification is not carried out in the TEE. If the user uses a weak PIN, the app cannot detect that the PIN is compromised.

On user enrollment, the PIN is first validated and then stored in a secure manner. The PIN value itself is not stored on the system. To prevent attempts to crack the PIN, its encrypted hashed value is stored.

On user verification, the same hashing process is applied to the PIN provided by the user, and then compared to the current value in the secure store. The PIN is considered valid if both values are the same.

To change the PIN, the user is required to provide their current PIN in addition to the new one, so it can be verified before replacing the value in secure storage.

caution

It is the responsibility of the app to handle the PIN entry. Given the sensitivity of this input value, special precautions should be taken to protect this value as well as possible.

Brute force attack prevention

The PIN authentication method is protected against non-sophisticated brute-force attacks. In the case of a failed PIN verification attempt, the user must wait for a predefined amount of time before being able to attempt PIN verification again. After the second failed attempt, a cool-down time is added as a penalty. The following table shows the added penalty for each failed attempt:

Number of failed attempts	Cool-Down in Seconds
1	0
2	0
3	60
4	180

Once the number of failed attempts is determined, the cool-down is calculated. If cool-down is required, the current timestamp is saved and if a new PIN verification is started before the end of the cool-down period, verification fails automatically.

When user interaction is initiated, the timeout for user interaction is extended with the cool-down time, to circumvent an unwanted timeout of the current operation.

info

As a last defensive mechanism, PIN Authentication registration is removed from the device completely after five failed attempts.

Authentication Key Revocation Scenarios

There are several scenarios that lead to FIDO authentication keys being revoked on the mobile client side:

1. Executing a deregistration or a remove local data operation.
2. Too many failed attempts entering the PIN of the PIN authentication method.
3. In iOS, removing the device lock screen (refer to Device lock screen).
4. In Android, removing the device lock screen (refer to Device lock screen) when using the device passcode authenticator.
5. Adding a new biometric credentials in the OS settings, if the biometric authenticator must be invalidated when doing so.