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 PIN, patrón y contraseña) proporciona el nivel más alto de seguridad. Los datos biométricos se encuentran en el nivel secundario de autenticación, lo que ofrece un equilibrio entre conveniencia y seguridad. La CDD de Android define tres clases de nivel de seguridad biométrico: clase 3 (anteriormente, seguro), 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 en la pantalla de bloqueo, pero solo los autenticadores seguros y no seguros pueden integrarse en las APIs de android.hardware.biometrics. En esta tabla, se describe cada autenticador y la funcionalidad que admite.
| Autenticador | 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) |
|---|---|---|---|---|
| BIOMETRIC_STRONG (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 de rostro y huellas dactilares. 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 del desbloqueo biométrico.
Fuente
Android 12
- Presenta la API de BiometricManager.Strings, que proporciona cadenas localizadas para apps que usan BiometricPrompt para la autenticación. El objetivo de estas cadenas es que reconozcan el dispositivo y proporcionen más detalles sobre los tipos de autenticación que se pueden usar.
- Incluye compatibilidad con el sensor de huellas dactilares ubicado debajo de la pantalla (UDFPS).
Android 11
- 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 de dispositivo. - Proporciona compatibilidad adicional con las claves de autenticación según el uso dentro de la clase BiometricPrompt.
Android 10
- Se presenta la
clase
BiometricManagerque los desarrolladores pueden usar para consultar la disponibilidad de la autenticación biométrica. - Incluye la integración de autenticación de huellas dactilares y reconocimiento facial 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 empaquetadas 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 desarrolladores tengan una experiencia biométrica sin problemas, 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 seguridad.Además, todas las implementaciones deben aprobar el módulo CTS CtsBiometricsTestCases.
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 seguridad solicitada. Si tu dispositivo admite más de uno, esta acción debería mostrar una lista de la que el usuario puede elegir.
Lineamientos de implementación de HAL
Sigue estos lineamientos de HAL biométricos 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 nunca se pueda acceder a los datos biométricos sin procesar ni a sus derivados (como las plantillas) desde fuera del entorno aislado seguro (como el TEE o el elemento seguro). Todos los datos almacenados deben estar encriptados con una clave específica del dispositivo que solo conoce el TEE (entorno de ejecución confiable). Si el hardware lo admite, limita el acceso del 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 la seguridad de los datos y otros ataques. Este requisito solo se aplica a los datos biométricos de Clase 3 (anteriormente Strong) y Clase 2 (anteriormente Débil).
- Para protegerte contra los ataques de reinyección, firma las plantillas biométricas con una clave privada específica del dispositivo. Para el estándar de encriptación avanzada (AES), como mínimo, firma una plantilla con la ruta de acceso, el grupo y el ID biométrico del sistema de archivos absolutos, de modo que los archivos de plantilla no se puedan usar en otro dispositivo ni para ninguna otra persona que no sea el usuario que los inscribió en el mismo dispositivo. Por ejemplo, evita copiar datos biométricos de un usuario diferente en el mismo dispositivo o desde otro.
- Si necesitas almacenar datos fuera del TEE, usa la ruta de acceso 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. El motivo es proteger la filtración de datos del usuario. Los dispositivos que no usan esta ruta de acceso deben realizar la limpieza después de que se quite el usuario. El CDD requiere que los datos biométricos y los archivos derivados se almacenen encriptados, en especial si no están en el TEE. Si esto no es posible debido a los requisitos de almacenamiento del entorno aislado seguro, agrega hooks para garantizar la eliminación de los datos cuando se quite el 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. Para tu implementación de BiometricPrompt, se debería preferir el valor biométrico de clase 3 (anteriormente Strong) como predeterminado, a menos que el usuario lo anule explícitamente. En ese caso, se debe mostrar un mensaje de advertencia en el que se expliquen los riesgos asociados con los datos biométricos (por ejemplo, Una foto tuya puede desbloquear tu 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 muestra esta API para implementar cadenas específicas del dispositivo. Si lo haces, asegúrate de que las cadenas nuevas se traduzcan para todas las configuraciones regionales que admite el dispositivo. Además, asegúrate de que se preserven las siguientes propiedades:
Método |
Propósito de la cadena |
Tipos de autenticación que se incluirán |
Si los datos biométricos y el bloqueo de pantalla son posibles |
|---|---|---|---|
getButtonLabel() |
Etiqueta de un botón que activa BiometricPrompt |
Solo tipos inscritos (si es posible) que satisfagan los requisitos del autenticador |
Usa una cadena solo biométrica (como "Usar huella dactilar") |
getPromptMessage() |
Mensaje que se muestra en BiometricPrompt durante la autenticación |
Solo tipos inscritos (si es posible) que satisfagan los requisitos del autenticador |
Usa una cadena de bloqueo de pantalla y datos biométricos combinados (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ánEnrollment) que satisfacen los requisitos del autenticador |
Usa una cadena de bloqueo de pantalla y datos biométricos combinados (como "Usar huella dactilar o bloqueo de pantalla"). |
Por ejemplo, considera un dispositivo que tiene un sensor facial de clase 2 con un rostro registrado, un PIN registrado y un sensor de huellas dactilares de clase 3 sin huellas dactilares registradas. En la siguiente tabla, se proporcionan strings de muestra 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 digital" (Solo la huella digital cumple con los requisitos del autenticador) |
"Usa tu huella dactilar para continuar" (Solo la huella dactilar cumple con los requisitos del autenticador) |
"Usar huella dactilar" (Solo la huella dactilar satisface los requisitos del autenticador) |
Biométrica de clase 2 (BIOMETRIC_WEAK) |
"Usa el rostro" (El rostro y la huella dactilar cumplen con los requisitos; solo se inscribe 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, y el dispositivo admite ambos) |
Bloqueo de pantalla (DEVICE_CREDENTIAL) |
"Usar PIN" (Cualquier bloqueo de pantalla satisface los requisitos; el PIN está inscrito) |
"Ingresa tu PIN para continuar" (cualquier bloqueo de pantalla satisface los requisitos; el PIN está inscrito) |
"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 cumplen con los requisitos; solo se inscribió el PIN) |
"Ingresa tu PIN para continuar" (La huella dactilar y el bloqueo de pantalla cumplen con los requisitos; solo está inscrito el PIN) |
"Usar huellas dactilares o bloqueo de pantalla" (Las huellas dactilares y cualquier bloqueo de pantalla satisfacen los requisitos) |
Biométrico de clase 2 O bloqueo de pantalla |
"Usar rostro" (El rostro, la huella dactilar y cualquier bloqueo de pantalla cumplen con 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 cumplen con 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 cumplen con los requisitos) |
Validación
Tu implementación de datos biométricos debe aprobar las siguientes pruebas:
- BiometricManager de CTS
- BiometricPrompt de CTS (pruebas de validación y pruebas detalladas que dependen del verificador)
- Sección de prueba biométrica de CtsVerifier: Debe aprobarse de forma individual con cada modalidad que admita el dispositivo.
Además, si tu dispositivo admite una biométrica que tiene un HIDL de AOSP (fingerprint@2.1, fingerprint@2.2, face1.0), debe aprobar la prueba de VTS relevante (fingerprint, face).