Authenticator Attestation (Full Basic / Surrogate Basic)

The FIDO UAF specification defines multiple authenticator attestation mechanisms.

The Nevis Mobile Authentication solutions support the following mechanisms:

1. Surrogate Basic Attestation
2. Full Basic Attestation

Surrogate Basic Attestation

Surrogate Basic Attestation is the default mechanism used and is supported by both Android and iOS authenticators. The attestation is self-signed, using the private key that corresponds to the public key included in the attestation object.

This approach ensures broad compatibility across platforms, requiring only secure hardware to store the key material.

Full Basic Attestation

Full Basic Attestation is supported exclusively by the Android SDK. It uses a hardware-stored key in the Trusted Execution Environment (TEE) to sign the attestation object, which is then verified against Google’s root certificates stored in the backend’s metadata file.

The primary advantage of Full Basic Attestation is its ability to guarantee that the key material resides in secure, certified hardware, which is verified during the registration process.

While Full Basic Attestation provides significant security benefits on Android, it has drawbacks, particularly a reduced pool of supported devices.

Device Compatibility

Full Basic Attestation is only compatible with Android devices that have Google-certified TEEs. While the majority of Android devices meet this requirement, there are notable exceptions:

• Huawei devices, which lack Google-certified hardware due to trade restrictions.
• Certain (older) models from other vendors within the fragmented Android ecosystem.

Because of this diversity, a comprehensive list of unsupported devices cannot be provided.

Authenticator Metadata

Full Basic Attestation relies on correct Android Authenticator Metadata.

Android Key Attestation Verification

Additional verification checks for Android key attestation (such as requiring a locked bootloader, verified boot state, or StrongBox security level) are configured via the ch.nevis.auth.fido.uaf.android-key-attestation-verifications policy extension in the FIDO UAF policy files.

This approach replaces the former android-verification-level instance configuration property and provides fine-grained, per-policy control over the attestation checks. The extension data field accepts either a single configuration object or an array of objects — when an array is provided, validation succeeds if the device matches any of the configurations (OR logic). This makes it possible, for example, to allow both standard verified-boot devices and custom-ROM devices (such as GrapheneOS) within the same policy. Refer to the policy configuration guide for the full list of supported fields and ready-to-use configurations equivalent to the previous strict and strict-strongbox levels.

Permissive mode

The permissive mode for FIDO UAF Full Basic Attestation allows to control the behavior of the Full Basic Attestation and Android key attestation policy extension checks in case they fail due to the client not being able to pass some of the requirements imposed by the hardware keystore compatibility or the Android key attestation verification checks.

Using this mode will allow clients to still successfully register. The nevisFIDO component will however create a log entry on WARN level starting with FIDO UAF Full Basic Attestation verification failed.. Additional information such as the user agent (indicating the device model) and the cause of the failure are included as well. This mode can be enabled by setting permissiveModeEnabled: true in the data field of the ch.nevis.auth.fido.uaf.android-key-attestation-verifications policy extension.

info

This mode can be useful when wanting to assess the number of mobile devices that would fail when rolling out Full Basic Attestation to end users. Be aware that using this property means Full Basic Attestation is not enforced, and that clients will be permitted to register even if they do not fulfill the full basic attestation requirements. So, in terms of security, this mode is equivalent to using Basis Surrogate Attestation.

Comparison

The table below compares the two attestation mechanisms in the Nevis Mobile Authentication SDK:

	Surrogate Basic	Full Basic
Android	✅	✅
iOS	✅	❌
Attestation signature	Self-signed	TEE certificate
Secure hardware proof	❌	✅
App signing certificate proof	❌	✅
Mobile device requirements	Secure hardware (TEE/Secure Enclave)	Google-certified secure hardware
Android OS version	7+	8+
iOS OS version	12.4+	❌
Nevis Identity Suite version	2.202105.x+	7.2411.0.x+
Mobile SDK version	all	3.8.x+

Stored credential registration attestation information

During the registration operation, nevisFIDO preserves additional information regarding the used attestation type in an optional nevisIDMs UAF credential field called attestationType.

The following results are available:

• fullBasic: The client registered using Full Basic Attestation.
• fullBasicPermissive The client registered with Full Basic Attestation and permissive mode was enabled.
• failedFullBasicPermissive The client registered with Full Basic Attestation and permissive mode was enabled and the client failed in performing Full Basic Attestation.
• surrogateBasic The client registered using Surrogate Basic Attestation.

Additional Resources

• Authenticator attestation is controlled via policies, the policy configuration examples show you how to configure the different attestation mechanisms.
• Android key attestation verification checks (boot state, security level, etc.) are configured via the ch.nevis.auth.fido.uaf.android-key-attestation-verifications policy extension. Permissive mode for failing checks is controlled via permissiveModeEnabled in the extension data.
• The Default FIDO UAF Authenticator Metadata for the Android authenticators contains the Google Root Public Key.