Known Issues

StrongBox on Android

Status

✅ Partially resolved - use Android SDK 4.2.0 with StrongBox opt-out.

Background: StrongBox and TEE

Android provides two hardware-backed key storage options for protecting FIDO UAF private keys:

• TEE (Trusted Execution Environment): A secure, isolated processing environment on the main System-on-Chip (SoC). The TEE runs alongside the main OS but is isolated from it by hardware and software controls. Android refers to this security level as SECURITY_LEVEL_TRUSTED_ENVIRONMENT. All Android devices that support a lock screen provide a TEE. For more information, see Android Keystore system.
• StrongBox: A dedicated hardware security module (HSM) that is physically separate from the main SoC - for example, an embedded Secure Element (eSE) or an on-SoC secure processing unit (iSE). Android refers to this security level as SECURITY_LEVEL_STRONGBOX. StrongBox requires Android 9 (API level 28) or higher and device vendor support. For more information, see the Android Compatibility Definition Document.

Both TEE and StrongBox are hardware-backed. In both cases, the private key never leaves the secure hardware. The main difference is the degree of physical isolation: StrongBox provides stronger resistance to physical and side-channel attacks because it uses a dedicated chip.

Issue

Some devices equipped with an Android StrongBox secure processor may have issues using StrongBox for storing and using key material. Problems have been experienced on several devices, such as (but not limited to) devices from Chinese manufacturers such as Xiaomi.

There are problems creating keys in StrongBox and using the created keys to sign registration assertions.

If the device is affected, the issue is likely to surface when using biometric authenticators during the registration operation: the biometric prompt appears, but after the user provides their biometrics, the operation fails. The issue is not consistently reproducible, even on the same device.

These issues are bugs in the vendor StrongBox implementations.

Affected components

• Android SDK 3.9.0 or later

Preventative action

The following actions have resolved the issue on some devices:

• Update the device to the latest OS version or security patch provided by the manufacturer.
• Restart the device.

Corrective action

Android SDK 4.2.0 introduced two corrective actions:

• Automatic fallback to TEE during key creation if key creation in StrongBox fails. This does not mitigate issues where StrongBox key creation succeeds but using the key for signing fails.
• An opt-out option: disable StrongBox and use only TEE by changing the Secure Defaults during registration. Access App integrators can configure this option as described in Allow storing keys in StrongBox.

The only long-term corrective action is for device vendors to roll out OS versions or patches that address the issues.

Security implications of opting out

Opting out of StrongBox means the SDK stores FIDO UAF key material in the TEE instead. Consider the following when making this decision:

• Both TEE and StrongBox are hardware-backed. The private key never leaves the secure hardware in either case.
• TEE provides strong isolation from the main OS and is the standard security level used across the Android ecosystem.
• StrongBox provides a higher degree of physical isolation because it uses a separate dedicated chip. This makes it more resistant to certain physical and side-channel attacks.
• For most deployments, TEE provides adequate security and is accepted by FIDO UAF Surrogate Basic Attestation.

Decision guide

Choose the approach that matches your security requirements and device compatibility needs:

Scenario	Configuration
Maximize device compatibility while retaining hardware-backed key storage	Opt out of StrongBox using allowStrongBox(false). Key material is stored in TEE.
Use StrongBox where available, fall back to TEE on incompatible devices	Use the default behavior (SDK 4.2.0+). The SDK attempts StrongBox first and falls back to TEE automatically.
Require StrongBox and reject devices that do not support it	Use the default StrongBox behavior and enforce StrongBox presence through FIDO UAF Full Basic Attestation backend policies. Note: registration will fail on devices without StrongBox support.

note

The allowStrongBox setting only affects new registrations. Changing the setting does not affect credentials that were registered with a different StrongBox configuration.

Jailbreak detection false positives in iOS 26

Status

✅ Resolved - use iOS SDK 4.1.2+

Issue

The Jailbreak detection guard has a low probability of triggering a tamper action when the device is not jailbroken leading to the SDK reporting a DeviceProtectionError.

Affected components

• iOS SDK - all versions

Preventative action

iOS SDK 4.1.1 disables the Jailbreak detection for iOS 26.

Corrective action

Update to iOS SDK 4.1.2+.

Open source operating systems

Status

⚠️ Active - not resolved

Issue

Open source operating systems such as GrapheneOS or LineageOS may present some performance issues while running tamper guards. This is applicable to all open source operating systems. The hardening framework in use does not support open source operating systems, therefore neither does our SDK.

Affected components

• Android SDK - all versions

Preventative action

Inform end users that open source operating systems are currently not supported.

Corrective action

In case support for custom operating systems is extended by the vendor of our hardening framework, Nevis will extend the SDK support to those operating systems as well. Contact our support for additional inquiries.

Android SDK 4.0 Full Basic Attestation

Status

✅ Resolved - use Android SDK 4.1.0+

Issue

Registration will fail on devices that do not have a Google certified chipset (such as older phones and some modern Chinese phones), even if Surrogate Basic attestation is allowed.

This is due to the SDK attempting to perform a FIDO UAF Full Basic Attestation check if the backend allows using it (e.g. using the default policy files).

Affected components

• Android SDK 4.0

Preventative action

The current mitigation is to allow clients to register using FIDO UAF Surrogate Basic Attestation. This can be achieved in one of two ways by; both involve changing the nevisFIDO backend configuration. Picking one of the mitigations below is sufficient.

1. Change the FIDO UAF policies

By changing the FIDO UAF policy files, the Android client can be forced to use FIDO UAF Surrogate Basic Attestation. Use the following policy file in the nevisFIDO component as a replacement of the default policy. It informs the clients to use Surrogate Basic. The iOS Authenticator policies remain unchanged.

Policy example forcing Android to use Surrogate Basic

{
  "accepted": [
    [
      {
        "aaid": ["F1D0#0001"]
      },
      {
        "attestationTypes": [ 15880 ],
        "assertionSchemes": ["UAFV1TLV"],
        "authenticationAlgorithms": [ 2, 9 ]
      }
    ],
    [
      {
        "aaid": ["F1D0#0002"]
      },
      {
        "attestationTypes": [ 15880 ],
        "assertionSchemes": ["UAFV1TLV"],
        "authenticationAlgorithms": [ 2, 9 ]
      }
    ],
    [
      {
        "aaid": ["F1D0#0003"]
      },
      {
        "attestationTypes": [ 15880 ],
        "assertionSchemes": ["UAFV1TLV"],
        "authenticationAlgorithms": [ 2, 9 ]
      }
    ],
    [
      {
        "aaid": ["F1D0#0004"]
      },
      {
        "attestationTypes": [ 15880 ],
        "assertionSchemes": ["UAFV1TLV"],
        "authenticationAlgorithms": [ 2, 9 ]
      }
    ],
    [
      {
        "aaid": ["F1D0#0005"]
      },
      {
        "attestationTypes": [ 15880 ],
        "assertionSchemes": ["UAFV1TLV"],
        "authenticationAlgorithms": [ 2, 9 ]
      }
    ],
    [
      {
        "aaid": ["F1D0#1001"]
      }
    ],
    [
      {
        "aaid": ["F1D0#1002"]
      }
    ],
    [
      {
        "aaid": ["F1D0#1003"]
      }
    ],
    [
      {
        "aaid": ["F1D0#1004"]
      }
    ],
    [
      {
        "aaid": ["F1D0#1005"]
      }
    ]
  ]
}

2. Enable permissive mode in nevisFIDO

Alternatively, you can enable permissive mode in the nevisFIDO component configuration file. This will allow a client to continue with the registration using Full Basic, because the validation error will just be logged.

fido-uaf.full-basic-attestation.android-permissive-mode-enabled: true

Corrective action

1. Android SDK 4.1+ will no longer attempt to perform FIDO UAF Full Basic Attestation as "best effort" if the server does not explicitly require it via policy.
2. The next nevisFIDO patch release will increase the number of devices that are allowed to register using full basic attestation.

iOS app groups / keychain access groups

Status

✅ Resolved - use iOS SDK 4.1.0+

Issue

The iOS SDK does not support app groups or keychain access groups. Using either of these features with apps using the iOS SDK will lead to key material of one app being removed as soon as another app is started. This is caused by the SDKs automatic credential cleanup feature ensuring a clean app state after reinstallation. The SDK is using the default keychain access group - it does not use or specify a specific one.

Affected components

• iOS SDK all versions

Preventative action

Do not use app groups or keychain access groups.

Corrective action

Nevis is working on a solution to rectify this.

Android Studio INSTALL_BASELINE_PROFILE_FAILED

Status

⚠️ Active - not resolved

Issue

When finalized application is run/installed from Android Studio on a device with Android 14 or later, starting the application may fail with the following error:

The application could not be installed: INSTALL_BASELINE_PROFILE_FAILED Installation failed due to: 'Baseline profile did not install: ....apk'

Affected components

• Finalized Android applications those include Android SDK 3.9.x with finalizer 6.x.

Effect

The application is installed, but Android Studio could not start it, you have to run it manually on the device.

Preventative action

There is a workaround to avoid this error:

1. In Android Studio click on menu item Run/Edit Configurations....
2. Select the used run configuration.
3. Change the value of the Installation Options/Deploy combo-box from Default APK to APK from app bundle.

Corrective action

Nevis is working on a solution to rectify this and automatically correct the serialisation issue with a future SDK plugin release.

Serialisation issue for PIN and password authenticator related errors affecting React Native and Flutter plugins

Status

• ✅ Flutter - Resolved
• ✅ React Native - Resolved

Issue

The application crashes if a custom policy is implemented for the Pin or the Password authenticator and in case of a failed validation, the integrator of the SDK plugin sends an error to the SDK without filling the cause field of the error.

Affected components

• React Native plugin - Android 3.5.2, 3.6.0, 3.7.0
• Flutter plugin - Android 3.6.0, 3.7.0

Affected users

Affected are user registrations and authentications performed with the following conditions:

• Android platform is used
• Custom PinPolicy or PasswordPolicy is implemented
• Any of the following errors are returned to the SDK plugin without providing a cause
  • PinEnrollmentCustomValidationError
  • PinChangeCustomValidationError
  • PasswordEnrollmentCustomValidationError
  • PasswordChangeRecoverableCustomValidationError

Effect

As a consequence of this issue, the application crashes in case a user provides an invalid pin / password during registration / authentication.

Preventative action

Always provide content in the cause field of the error given to the SDK plugin in case of a failed pin or password validation check.

Non-unique device identifier (Android SDK)

Status

✅ Resolved

Issue

The device identifier generated during initial user registration is not unique and does not allow to differentiate between different installations of the app over multiple physical devices.

Affected components

• Android SDK 3.6.1, 3.6.2
• React Native plugin 3.6.0, 3.6.1
• Flutter plugin 3.6.0

Affected users

Affected are user registrations performed with the following versions:

• Android SDK 3.6.1 and 3.6.2
• React Native plugin 3.6.0 and 3.6.1
• Flutter plugin 3.6.0

Unaffected user registrations are:

• User registrations performed with prior versions to the ones listed above
• iOS users are not affected

Am I affected? Nevis Identity Suite

The following SQL query will list potentially affected users:

Query for potentially affected users

select c.USER_ID, v.ENTITY_ID as "CREDENTIAL_ID", v.VALUE as "DEVICE_ID", ua.VALUE as "USER_AGENT"
from TIDMA_PROPERTY_VALUE v
         join TIDMA_CREDENTIAL c on v.ENTITY_ID = c.CREDENTIAL_ID
         left join TIDMA_PROPERTY_VALUE ua on ua.ENTITY_ID = c.CREDENTIAL_ID and ua.PROPERTY_ID = (select PROPERTY_ID from TIDMA_PROPERTY where name = "fidouaf_user_agent")
where v.VALUE in (
    select value FROM TIDMA_PROPERTY_VALUE
    where PROPERTY_ID = (select PROPERTY_ID from TIDMA_PROPERTY where name = "fidouaf_device_id")
    group by VALUE having count(VALUE) > 1
)
  and exists(
    select value FROM TIDMA_PROPERTY_VALUE pv
    where pv.ENTITY_ID = v.ENTITY_ID and pv.PROPERTY_ID = (select PROPERTY_ID from TIDMA_PROPERTY where name = "fidouaf_user_agent")
      and pv.value like "%Android%"
);

Effect

info

This issue has no direct impact for end users and is not a security relevant issue.

As a consequence of this issue, the device identifier cannot be trusted to be unique for an app installation on a physical device for affected users.

From a backend perspective, this affects the following attributes:

• Nevis Authentication Cloud: DeviceRef, see Users endpoint HTTP API and Can the Device Ref of the authenticator change?
• Nevis Identity Suite: The fidouaf_device_id attribute in the nevisIDM Generic Dispatch Target credential as well as in the UAF credential.

Preventative action

Android SDK 3.7.0 addresses the issue for new user registrations. It is therefore recommended to move to this version as soon as possible to prevent any occurrence of the issue.