Los datos biométricos ofrecen una forma más conveniente, pero potencialmente menos segura, de confirmar tu identidad con un dispositivo. En el modelo de autenticación por niveles, la autenticación principal (es decir, las modalidades basadas en factores de conocimiento, como el PIN, el patrón y la contraseña) proporciona el nivel más alto de seguridad. Los datos biométricos se encuentran en el nivel secundario de autenticación y ofrecen un equilibrio entre comodidad y seguridad. El CDD de Android define tres clases de seguridad biométrica: clase 3 (anteriormente, segura), clase 2 (anteriormente, débil) y clase 1 (anteriormente, conveniente). Cada clase tiene un conjunto de requisitos previos, privilegios y restricciones. Consulta el CDD anterior para obtener más detalles. Las tres clases pueden integrarse con la pantalla de bloqueo, pero solo los autenticadores seguros y débiles pueden integrarse con las APIs de android.hardware.biometrics. En esta tabla, se describe cada autenticador y la funcionalidad que admite.
| Authenticator | Pantalla de bloqueo | Integración de BiometricPrompt | Almacén de claves (clave basada en el tiempo) | Almacén de claves (clave basada en la operación) |
|---|---|---|---|---|
| BIOMÉTRICO_FUERTE (clase 3) | Sí | Sí | Sí | Sí |
| BIOMETRIC_WEAK (clase 2) | Sí | Sí | No | No |
| BIOMETRIC_CONVENIENCE (Clase 1) |
Sí | No | No | No |
| DEVICE_CREDENTIAL | Sí | Sí | Sí | Sí |
El framework de Android incluye compatibilidad con la autenticación biométrica facial y de huella dactilar. Android se puede personalizar para admitir otras modalidades biométricas (como el iris). Sin embargo, la integración biométrica dependerá de la seguridad biométrica, no de la modalidad. Para obtener más detalles sobre las especificaciones de seguridad biométrica, consulta Cómo medir la seguridad de desbloqueo biométrico.
Fuente
Android 12
- Se introduce la API de BiometricManager.Strings, que proporciona cadenas localizadas para las apps que usan BiometricPrompt para la autenticación. Estas cadenas están diseñadas para tener en cuenta el dispositivo y proporcionar más especificidad sobre qué tipos de autenticación se pueden usar.
- Incluye compatibilidad con el sensor de huellas dactilares ubicado debajo de la pantalla (UDFPS).
Android 11
- Se presenta la interfaz BiometricManager.Authenticators, que proporciona constantes que los desarrolladores pueden usar para especificar los tipos de autenticación que aceptan sus apps.
- Se agregó la acción de intent
ACTION_BIOMETRIC_ENROLL, que los desarrolladores pueden usar para dirigir al usuario a inscribir un método de autenticación que cumpla con los requisitos de sus apps. - Se agregó el método
AuthenticationResult#getAuthenticationType(), que los desarrolladores pueden usar para verificar si el usuario se autenticó con una credencial biométrica o una credencial de dispositivo. - Proporciona compatibilidad adicional con las claves de autenticación según el uso dentro de la clase BiometricPrompt.
Android 10
- Se introduce la
clase
BiometricManagerque los desarrolladores pueden usar para consultar la disponibilidad de la autenticación biométrica. - Incluye la integración de la autenticación por huella dactilar y rostro para
BiometricPrompt
Android 9
- Incluye la integración de huellas dactilares solo para
BiometricPrompt. - Se dejó de usar la clase FingerprintManager. Si tus apps del sistema y las incluidas en el paquete usan esta clase, actualízalas para que usen
BiometricPromptyBiometricManageren su lugar. - Se actualizaron las pruebas del verificador de CTS
FingerprintManagerpara probarBiometricPromptconBiometricPromptBoundKeysTest.
Implementación
Para garantizar que los usuarios y los desarrolladores tengan una experiencia biométrica fluida, integra tu pila de datos biométricos con las APIs de BiometricPrompt, BiometricManager y ACTION_BIOMETRIC_ENROLL. Los dispositivos con sensores biométricos deben cumplir con estos requisitos de resistencia.Además, todas las implementaciones deben aprobar el módulo CtsBiometricsTestCases del CTS.
Para integrar tu pila de datos biométricos con la API de ACTION_BIOMETRIC_ENROLL, haz lo siguiente:
- Modifica BiometricEnrollActivity para presentar tu flujo de inscripción. Ten en cuenta que tu dato biométrico solo se puede presentar si cumple con la solidez solicitada. Si tu dispositivo admite más de una, esta acción debe presentar una lista de la que el usuario pueda elegir.
Lineamientos de implementación del HAL
Sigue estos lineamientos de HAL biométrico para garantizar que los datos biométricos no se filtren y se quiten cuando se quite un usuario de un dispositivo:
- Asegúrate de que los datos biométricos sin procesar o sus derivados (como las plantillas) nunca sean accesibles desde fuera del entorno aislado seguro (como el TEE o el elemento seguro). Todos los datos almacenados deben encriptarse con una clave específica del dispositivo que solo conoce el entorno de ejecución confiable (TEE). Si el hardware lo admite, limita el acceso al hardware al entorno aislado seguro y protégelo con una política de SELinux. Haz que el canal de comunicación (por ejemplo, SPI, I2C) sea accesible solo para el entorno aislado seguro con una política de SELinux explícita en todos los archivos del dispositivo.
- La adquisición, el registro y el reconocimiento biométricos deben ocurrir dentro del entorno aislado seguro para evitar violaciones de seguridad y otros ataques. Este requisito solo se aplica a los datos biométricos de clase 3 (anteriormente, sólidos) y clase 2 (anteriormente, débiles).
- Para protegerte contra los ataques de reinyección, firma las plantillas biométricas con una clave privada específica del dispositivo. En el caso del Estándar de Encriptación Avanzada (AES), como mínimo, firma una plantilla con la ruta absoluta del sistema de archivos, el grupo y el ID biométrico de modo que los archivos de plantilla no funcionen en otro dispositivo ni para ninguna persona que no sea el usuario que los inscribió en el mismo dispositivo. Por ejemplo, impedir la copia de datos biométricos de un usuario diferente en el mismo dispositivo o desde otro dispositivo
- Si necesitas almacenar datos fuera del TEE, usa la ruta del sistema de archivos que proporciona
setActiveUser() HIDL methodo proporciona otra forma de borrar todos los datos de la plantilla del usuario cuando se quite al usuario. El motivo es proteger la filtración de datos del usuario. Los dispositivos que no usan esta ruta deben realizar una limpieza después de que se quite al usuario. El CDD exige que los datos biométricos y los archivos derivados se almacenen de forma encriptada, en especial si no están en el TEE. Si esto no es factible debido a los requisitos de almacenamiento del entorno aislado seguro, agrega hooks para garantizar la eliminación de los datos cuando se quite al usuario o se borre el dispositivo. Consulta LockSettingsService.removeBiometricsForUser().
Personalización
Si tu dispositivo admite varios datos biométricos, el usuario debería poder especificar uno predeterminado en la configuración. Tu implementación de BiometricPrompt debe preferir la biometría de clase 3 (anteriormente, fuerte) como predeterminada, a menos que el usuario la anule explícitamente. En ese caso, se debe mostrar un mensaje de advertencia que explique los riesgos asociados con la biometría (por ejemplo, Es posible que una foto tuya desbloquee el dispositivo).
Cadenas de autenticación específicas del dispositivo
A partir de Android 12, las cadenas de autenticación contextual están disponibles para los desarrolladores a través de la API de BiometricManager.Strings. Puedes personalizar los valores de recursos que devuelve esta API para implementar cadenas específicas del dispositivo. Si lo haces, asegúrate de que todas las cadenas nuevas se traduzcan para todas las configuraciones regionales que admite el dispositivo. Además, asegúrate de que se conserven las siguientes propiedades:
Method |
Propósito de la cadena |
Tipos de autenticación que se incluirán |
Si son posibles los datos biométricos y el bloqueo de pantalla |
|---|---|---|---|
getButtonLabel() |
Etiqueta de un botón que activa BiometricPrompt |
Solo los tipos inscritos (si es posible) que satisfagan los requisitos del autenticador |
Usa la cadena biometric-only (solo biométrica) (por ejemplo, "Usar huella dactilar"). |
getPromptMessage() |
Mensaje que se muestra en BiometricPrompt durante la autenticación |
Solo los tipos inscritos (si es posible) que satisfagan los requisitos del autenticador |
Usa la cadena combinada de bloqueo de pantalla y datos biométricos (p. ej., "Usa tu huella dactilar o PIN para continuar"). |
getSettingName() |
Nombre de un parámetro de configuración que habilita BiometricPrompt para la autenticación |
Todos los tipos compatibles con el dispositivo (incluso si no están inscritos) que satisfacen los requisitos del autenticador |
Usa la cadena combinada de bloqueo de pantalla y datos biométricos (por ejemplo, "Usa tu huella dactilar o el bloqueo de pantalla"). |
Por ejemplo, considera un dispositivo que tiene un sensor facial de clase 2 con un rostro inscrito, un PIN inscrito y un sensor de huellas dactilares de clase 3 sin huellas dactilares inscritas. En la siguiente tabla, se proporcionan cadenas de ejemplo para cada combinación de autenticadores permitidos y el método BiometricManager.Strings invocado:
Autenticadores permitidos |
getButtonLabel() |
getPromptMessage() |
getSettingName() |
|---|---|---|---|
Biométrica de clase 3 (BIOMETRIC_STRONG) |
"Usar huella dactilar" (Solo la huella dactilar satisface los requisitos del autenticador) |
"Usa tu huella digital para continuar" (Solo la huella digital satisface los requisitos del autenticador) |
"Usar huella dactilar" (Solo la huella dactilar satisface los requisitos del autenticador) |
Biométrica de clase 2 (BIOMETRIC_WEAK) |
"Usar rostro" (El rostro y la huella dactilar cumplen con los requisitos; solo se inscribió el rostro) |
"Usa tu rostro para continuar" (El rostro y la huella dactilar cumplen con los requisitos; solo se inscribió el rostro) |
"Usar rostro o huella dactilar" (El rostro y la huella dactilar cumplen con los requisitos; el dispositivo admite ambos) |
Bloqueo de pantalla (DEVICE_CREDENTIAL) |
"Usar PIN" (Cualquier bloqueo de pantalla satisface los requisitos; se registró un PIN) |
"Ingresa tu PIN para continuar" (Cualquier bloqueo de pantalla satisface los requisitos; el PIN está registrado) |
"Usar bloqueo de pantalla" (Cualquier bloqueo de pantalla satisface los requisitos) |
Datos biométricos de clase 3 O bloqueo de pantalla |
"Usar PIN" (La huella dactilar y cualquier bloqueo de pantalla satisfacen los requisitos; solo se registró el PIN) |
"Ingresa tu PIN para continuar" (La huella dactilar y cualquier bloqueo de pantalla satisfacen los requisitos; solo se registró el PIN) |
"Usar huella dactilar o bloqueo de pantalla" (La huella dactilar y cualquier bloqueo de pantalla satisfacen los requisitos) |
Datos biométricos de clase 2 O bloqueo de pantalla |
"Usar rostro" (El rostro, la huella dactilar y cualquier bloqueo de pantalla satisfacen los requisitos; el rostro está inscrito y reemplaza el PIN) |
"Usa tu rostro o PIN para continuar" (El rostro, la huella dactilar y cualquier bloqueo de pantalla satisfacen los requisitos; el rostro y el PIN están inscritos) |
"Usar datos biométricos o bloqueo de pantalla" (El rostro, la huella dactilar y cualquier bloqueo de pantalla satisfacen los requisitos) |
Validación
Tu implementación biométrica debe superar las siguientes pruebas:
- CTS BiometricManager
- CTS BiometricPrompt (prueba de cordura, las pruebas detalladas dependen del verificador)
- Sección de la prueba biométrica de CtsVerifier: Debe aprobarse de forma individual con cada modalidad que admita el dispositivo
Además, si tu dispositivo admite un sistema biométrico que tiene un HIDL de AOSP ([email protected], [email protected], face1.0), debe aprobar su prueba de VTS pertinente (fingerprint, face).