Known Issues

Open source operating systems

Status

⚠️ Active - not resolved

Issue

Open source operating systems such as GrapheneOS or LineageOS may trigger the RootedError or a DeviceProtectionError. 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.

GrapheneOS workaround

There is a workaround to allow the SDK to run on GrapheneOS. However the workaround lessens the overall security of GrapheneOS as it disables secure app spawning therefore the end user needs to carefully consider it.

1. In the system settings, navigate to Security & privacy
2. Scroll down to the Other settings section
3. Select Exploit protection
4. Scroll down to Secure app spawning
5. Disable use secure app spawning
6. Reboot the device

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.