O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Biometria

Biometric factors allow for secure authentication on the Android platform. The Android framework includes face and fingerprint biometric authentication. Android can be customized to support other forms of biometric authentication (such as Iris). All biometric implementations must meet security specifications and have a strong rating in order to participate in the BiometricPrompt class. Biometrics are measured with the Imposter Accept Rate (IAR) and Spoof Accept Rate (SAR).

For more details on biometric security specifications, see Measuring Biometric Unlock Security.

Source

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. Devices that enable BiometricPrompt for any modality, including face, fingerprint, and iris, must adhere to these strength requirements. If they don't meet the strength requirements, then they can't implement this class.
To integrate your biometric stack with BiometricPrompt and BiometricManager:

  • Ensure that your <Modality>Service is properly hooked up to BiometricService and hooks the authenticate() method. Common modalities (fingerprint, face) extend from a common superclass. If you need to integrate an unsupported modality, follow the fingerprint/face example and the CDD guidelines for biometrics.
  • Ensure that your new modality is properly supported in SystemUI. There are default BiometricPrompt user interfaces for fingerprint and face
  • Update the framework to honor KEYGUARD_DISABLE_* flags for the added biometrics.
  • Ensure that your device passes the CTS and CtsVerifier tests for every modality that you've integrated into BiometricPrompt/BiometricManager. For example, if you have both fingerprint and face, the tests must pass individually for each of them.
BiometricPrompt architecture
Figure 1. BiometricPrompt architecture

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 sensor driver or secure isolated environment (such as the TEE or Secure Element).
  • 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 strong biometrics.
  • Store only the encrypted form of biometric data or derivatives on the file system, even if the file system itself is encrypted.
  • 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.
  • Use the file-system path provided by the set_active_group()function or provide another way to erase all user template data when the user is removed. It's strongly recommended that biometric template files be stored as encrypted in the path provided. 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.

Customization

If your device supports multiple biometrics, the user should be able to specify a default in settings. Your BiometricPrompt implementation should prefer the 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)

Validation

Your biometric implementation must pass the following tests:

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