Authenticator Attestation (Full Basic / Surrogate Basic)
The FIDO UAF specification defines multiple authenticator attestation mechanisms.
The Nevis Mobile Authentication solutions support the following mechanisms:
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.
Verification Levels
The Nevis product supports multiple verification levels for Full Basic Attestation:
- Default: Verifies that the key material is stored in Google-certified hardware.
- Strict: Enforces additional checks, increasing security at the cost of further narrowing the pool of supported devices:
- Boot state is verified.
- The device bootloader is locked.
- The Keymaster version is 2 or newer.
- The Keymaster security level is either TEE or StrongBox.
- The AttestationApplicationId signature digest matches one of the known Android Facets.
As the server checks the AttestationApplicationId
's certificate digest against the facet entries, it requires the usage of the correct Android APK key hash used by the app signing certificate.
This implies that you cannot use wildcard facet IDs intended for development purposes with this check.
As this check verifies that the application using the SDK has been signed with an application signing certificate configured in the Nevis backend, it can be considered a "light" Android App Attestation, because only the real and genuine app is able to provide this information to the backend. A fake app would fail this check as it is not signed with the correct application signing certificate. However, it's not a complete replacement of app attestation as this check is only performed during registration and does not provide additional checks provided by the Google Play Integrity API.
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+ |
Additional Resources
- Authenticator attestation is controlled via policies, the policy configuration examples show you how to configure the different attestation mechanisms.
- The Full Basic Attestation verification level is controlled via nevisFIDO instance configuration.