Biometrics

Biometrics offer a more convenient, but potentially less secure way of confirming your identity with a device. Under the tiered authentication model, primary authentication (that as, knowledge-factor based modalities such as PIN, pattern, and password) provides the highest level of security. Biometrics are in the secondary tier of authentication, offering a balance of convenience and security. The Android CDD defines three classes of biometric strength: Class 3 (formerly Strong), Class 2 (formerly Weak), and Class 1 (formerly Convenience). Each class has a set of prerequisites, privileges, and constraints - please see the CDD above for more details. All three classes are allowed to integrate with lockscreen, but only Strong and Weak authenticators are allowed to integrate with the android.hardware.biometrics APIs. This table describes each authenticator and the functionality they support.

Authenticator	Lockscreen	BiometricPrompt Integration	Keystore (time-based key)	Keystore (operation-based key)
BIOMETRIC_STRONG (Class 3)	Yes	Yes	Yes	Yes
BIOMETRIC_WEAK (Class 2)	Yes	Yes	No	No
BIOMETRIC_CONVENIENCE (Class 1)	Yes	No	No	No
DEVICE_CREDENTIAL	Yes	Yes	Yes	Yes

The Android framework includes support for face and fingerprint biometric authentication. Android can be customized to support other biometric modalities (such as Iris). However, biometric integration will depend on biometric security, not modality. For more details on biometric security specifications, see Measuring Biometric Unlock Security.

Source

Android 12

• Introduces the BiometricManager.Strings API, which provides localized strings for apps that use BiometricPrompt for authentication. These strings are intended to be device-aware and provide more specificity about which authentication type(s) may be used.
• Includes under-display fingerprint sensor (UDFPS) support.

Android 11

• Introduces the BiometricManager.Authenticators interface, which provides constants that developers can use to specify the types of authentication accepted by their apps.
• Adds the ACTION_BIOMETRIC_ENROLL intent action, which developers can use to direct the user to enroll an authentication method that meets the requirements of their apps.
• Adds the AuthenticationResult#getAuthenticationType() method, which developers can use to check whether the user authenticated using a biometric credential or a device credential.
• Provides additional support for auth-per-use keys within the BiometricPrompt class.

Android 10

• Introduces the BiometricManager class that developers can use to query the availability of biometric authentication.
• Includes fingerprint and face authentication integration for BiometricPrompt

Android 9

• Includes fingerprint integration only for BiometricPrompt.
• Deprecates the FingerprintManager class. If your bundled and system apps use this class, update them to use BiometricPrompt and BiometricManager instead.
• Updated the FingerprintManager CTS verifier tests to test BiometricPrompt using BiometricPromptBoundKeysTest.

Implementation

To ensure that users and developers have a seamless biometric experience, integrate your biometric stack with BiometricPrompt, BiometricManager, and ACTION_BIOMETRIC_ENROLL APIs. Devices with biometric sensors must adhere to these strength requirements.In addition, all implementations must pass the CtsBiometricsTestCases CTS module.

To integrate your biometric stack with the ACTION_BIOMETRIC_ENROLL API:

1. Modify the BiometricEnrollActivity to present your enrollment flow. Note that your biometric can be presented only if it meets the requested strength. If your device supports more than one, this action should present a list the user can choose from.

HAL implementation guidelines

Follow these biometric HAL guidelines to ensure that biometric data is not leaked and is removed when a user is removed from a device:

• Make sure that raw biometric data or derivatives (such as templates) are never accessible from outside the secure isolated environment (such as the TEE or Secure Element). All stored data must be encrypted with a device-specific key known only to the TEE (Trusted Execution Environment). If the hardware supports it, limit hardware access to the secure isolated environment and protect it with an SELinux policy. Make the communication channel (for example, SPI, I2C) accessible only to the secure isolated environment with an explicit SELinux policy on all device files.
• Biometric acquisition, enrollment, and recognition must occur inside the secure isolated environment to prevent data breaches and other attacks. This requirement only applies to Class 3 (formerly Strong) and Class 2 (formerly Weak) biometrics.
• To protect against replay attacks, sign biometric templates with a private, device-specific key. For Advanced Encryption Standard (AES), at a minimum sign a template with the absolute file-system path, group, and biometric ID such that template files are inoperable on another device or for anyone other than the user that enrolled them on the same device. For example, prevent copying biometric data from a different user on the same device or from another device.
• If you need to store data outside of the TEE, use the file-system path provided by the setActiveUser() HIDL method or provide another way to erase all user template data when the user is removed. The reason is to protect leaking of user data. Devices that don't use this path must clean up after the user is removed. It's required by CDD that biometric data and derivative files be stored encrypted - especially if not in TEE If this is infeasible due to the storage requirements of the secure isolated environment, add hooks to ensure removal of the data when the user is removed or the device is wiped. See LockSettingsService.removeBiometricsForUser()

Customization

If your device supports multiple biometrics, the user should be able to specify a default in settings. Your BiometricPrompt implementation should prefer the Class 3 (formerly Strong) biometric as the default unless the user explicitly overrides it, then a warning message needs to be displayed explaining the risks associated with the biometric (for example, A photo of you may unlock your device)

Device-specific authentication strings

Starting in Android 12, contextual authentication strings are made available to developers through the BiometricManager.Strings API. You may customize the resource values returned by this API to implement device-specific strings. If you do, ensure that any new strings are translated for all locales that the device supports. Additionally, make sure the following properties are preserved:

Method	String purpose	Authentication type(s) to include	If biometric(s) and screen lock are both possible
getButtonLabel()	Label for a button that triggers BiometricPrompt	Enrolled types only (if possible) that satisfy authenticator requirements	Use biometric-only string (such as, "Use fingerprint")
getPromptMessage()	Message shown on BiometricPrompt while authenticating	Enrolled types only (if possible) that satisfy authenticator requirements	Use combined biometric and screen lock string (e.g. "Use your fingerprint or PIN to continue")
getSettingName()	Name of a setting that enables BiometricPrompt for authentication	All types supported by the device (even if not enrolled) that satisfy authenticator requirements	Use combined biometric and screen lock string (such as, "Use fingerprint or screen lock")

For example, consider a device that has a Class 2 face sensor with an enrolled face, an enrolled PIN, and a Class 3 fingerprint sensor with no enrolled fingerprints. The following table provides sample strings for each combination of allowed authenticators and invoked BiometricManager.Strings method:

Allowed authenticators	getButtonLabel()	getPromptMessage()	getSettingName()
Class 3 biometric (BIOMETRIC_STRONG)	"Use fingerprint" (Only fingerprint satisfies authenticator requirements)	"Use your fingerprint to continue" (Only fingerprint satisfies authenticator requirements)	"Use fingerprint" (Only fingerprint satisfies authenticator requirements)
Class 2 biometric (BIOMETRIC_WEAK)	"Use face" (Face and fingerprint satisfy requirements; only face is enrolled)	"Use your face to continue" (Face and fingerprint satisfy requirements; only face is enrolled)	"Use face or fingerprint" (Face and fingerprint satisfy requirements; device supports both)
Screen lock (DEVICE_CREDENTIAL)	"Use PIN" (Any screen lock satisfies requirements; PIN is enrolled)	"Enter your PIN to continue" (Any screen lock satisfies requirements; PIN is enrolled)	"Use screen lock" (Any screen lock satisfies requirements)
Class 3 biometric OR screen lock	"Use PIN" (Fingerprint and any screen lock satisfy requirements; only PIN is enrolled)	"Enter your PIN to continue" (Fingerprint and any screen lock satisfy requirements; only PIN is enrolled)	"Use fingerprint or screen lock" (Fingerprint and any screen lock satisfy requirements)
Class 2 biometric OR screen lock	"Use face" (Face, fingerprint, and any screen lock satisfy requirements; face is enrolled and supersedes PIN)	"Use your face or PIN to continue" (Face, fingerprint, and any screen lock satisfy requirements; face and PIN are enrolled)	"Use biometrics or screen lock" (Face, fingerprint, and any screen lock satisfy requirements)

Validation

Your biometric implementation must pass the following tests:

• CTS BiometricManager
• CTS BiometricPrompt (sanity, in-depth testing relies on verifier)
• CtsVerifier Biometric Test section: Must pass individually with each modality that the device supports

In addition, if your device supports a biometric that has an AOSP HIDL (fingerprint@2.1, fingerprint@2.2, face1.0), it must pass its relevant VTS test (fingerprint, face)