Descripción general
La autenticación facial permite a los usuarios desbloquear el dispositivo simplemente mirando la parte frontal. Android 10 agrega compatibilidad para una nueva pila de autenticación facial que puede procesar marcos de cámara de forma segura, lo que preserva la seguridad y privacidad durante la autenticación facial en hardware compatible. Android 10 también facilita que las implementaciones que cumplen con la seguridad permitan la integración de aplicaciones para transacciones de banca en línea, por ejemplo, y otros servicios.
La pila de autenticación facial de Android es una nueva implementación en Android 10. La nueva implementación incluye las interfaces IBiometricsFace.hal,
IBiometricsFaceClientCallback.hal,
y types.hal.
Arquitectura
La API de BiometricPrompt incluye toda la autenticación biométrica, incluidos el rostro, el dedo y el iris. El HAL de rostro interactúa con los siguientes componentes.
Figura 1: Pila biométrica
FaceManager
FaceManager es una interfaz privada que mantiene una conexión con FaceService. Keyguard la usa para acceder a la autenticación facial con una IU personalizada. Las apps no tienen acceso a FaceManager y, en su lugar, deben usar BiometricPrompt.
FaceService
Esta es la implementación del framework que administra el acceso al hardware de autenticación facial. Contiene máquinas de estado básicas de inscripción y autenticación, así como varios otros asistentes (por ejemplo, enumeración). Debido a problemas de estabilidad y seguridad, no se permite la ejecución de código de proveedor en este proceso. Se accede a todo el código del proveedor a través de la interfaz HIDL de Face 1.0.
faced
Este es un ejecutable de Linux que implementa la interfaz HIDL de Face 1.0 que usa FaceService. Se registra como IBiometricsFace@1.0 para que FaceService pueda encontrarlo.
Implementación
HIDL de rostro
Para implementar el HIDL de rostro, debes implementar todos los métodos de IBiometricsFace.hal
en una biblioteca específica del proveedor.
Mensajes de error
Los mensajes de error se envían mediante una devolución de llamada y devuelven la máquina de estado al estado inactivo después de enviarse. La mayoría de los mensajes tienen una cadena correspondiente para el usuario para informarle sobre el error, pero no todos los errores tienen esta cadena. Para obtener más información sobre los mensajes de error, consulta
types.hal.
Todos los mensajes de error representan un estado terminal, lo que significa que el framework supone que el HAL vuelve a un estado inactivo después de enviar un mensaje de error.
Mensajes de adquisición
Los mensajes de adquisición se entregan durante la inscripción o la autenticación, y tienen como objetivo guiar al usuario hacia una inscripción o autenticación exitosa.
Cada número ordinal tiene
un mensaje asociado del FaceAuthenticationManager.java
archivo. Se pueden agregar mensajes específicos del proveedor, siempre que se proporcionen las cadenas de ayuda correspondientes. Los mensajes de adquisición no son estados terminales en sí mismos; se espera que el HAL envíe tantos como sea necesario para completar la inscripción o la autenticación actuales. Si un mensaje de adquisición da como resultado un estado terminal en el que no se puede avanzar, el HAL debe seguir los mensajes de adquisición con un mensaje de error, por ejemplo, cuando la imagen está demasiado oscura y permanece así para que se pueda avanzar. En este caso, es
razonable enviar UNABLE_TO_PROCESS después de varios intentos, pero no se puede avanzar más.
Hardware
Para que los dispositivos cumplan con los requisitos biométricos sólidos de Android 10, deben tener hardware seguro para garantizar la integridad de los datos faciales y la comparación de autenticación definitiva. En el documento de Definición de compatibilidad de Android (CDD), se describe el nivel de seguridad requerido y la tasa de aceptación de falsificación (SAR) aceptable. Se requiere un entorno de ejecución confiable (TEE) para el procesamiento y el reconocimiento seguros. Además, se requiere hardware de cámara seguro para evitar ataques de inyección en la autenticación facial. Por ejemplo, las páginas de memoria asociadas para los datos de imagen podrían tener privilegios y marcarse como de solo lectura para que solo el hardware de la cámara pueda actualizarlas. Lo ideal es que ningún proceso tenga acceso, excepto el TEE y el hardware.
Dado que el hardware de autenticación facial varía considerablemente, es necesario desarrollar controladores específicos del hardware para habilitar la autenticación facial, según la arquitectura específica del dispositivo. Por lo tanto, no hay una implementación de referencia para faced.
Métodos
Todos los métodos siguientes son asíncronos y deben volver inmediatamente al framework. De lo contrario, el sistema será lento y se producirán restablecimientos de Watchdog. Se recomienda tener una cola de mensajes con varios subprocesos para evitar bloquear la persona que llama. Todas las solicitudes GET deben almacenar en caché la información cuando sea posible para que la persona que llama se bloquee durante un tiempo mínimo.
| Método | Descripción |
|---|---|
setCallback() |
FaceService llama a este método para enviar todos los mensajes de vuelta a sí mismo. |
setActiveUser() |
Establece el usuario activo, al que se aplican todas las operaciones HAL posteriores. La autenticación siempre es para este usuario hasta que se vuelve a llamar a este método. |
revokeChallenge() |
Finaliza la transacción segura invalidando el desafío generado
por generateChallenge(). |
enroll() |
Inscribe el rostro de un usuario. |
cancel() |
Cancela la operación actual (por ejemplo, inscribir, autenticar,
quitar o enumerar) y devuelve faced al estado inactivo. |
enumerate() |
Enumera todas las plantillas faciales asociadas con el usuario activo. |
remove() |
Quita una plantilla facial o todas las plantillas faciales asociadas con el usuario activo. |
authenticate() |
Autentica al usuario activo. |
userActivity() |
Este método solo debe usarse cuando el HAL está en estado de autenticación o
en espera. Si usas este método cuando el HAL no está en uno de estos
estados, se muestra OPERATION_NOT_SUPPORTED. Si llamas a
este método mientras el HAL ya se está autenticando, es posible que se extienda el
tiempo que el sistema busca un rostro. |
resetLockout() |
Cuando se rechazan demasiados rostros, faced debe entrar en un estado de bloqueo (LOCKOUT o LOCKOUT_PERMANENT). Cuando lo hace, debe enviar el tiempo restante al framework para que pueda mostrarlo al usuario. Al igual que con setFeature(), este método requiere un
token de autenticación de hardware (HAT) activo para restablecer de forma segura el estado interno. Restablece el bloqueo
solo para el usuario actual. |
Los tres métodos restantes son síncronos y deben bloquearse durante el tiempo mínimo para evitar detener el framework.
| Método | Descripción |
|---|---|
generateChallenge() |
Genera un token aleatorio único y seguro a nivel criptográfico que se usa para indicar el inicio de una transacción segura. |
setFeature() |
Habilita o inhabilita una función para el usuario actual. Por motivos de seguridad razones, esto requiere un HAT para verificar el PIN, el patrón o la contraseña del usuario en comparación con el desafío anterior. |
getFeature() |
Recupera el estado de habilitación actual de la función, según lo dicta
el valor predeterminado o una llamada a setFeature() anterior. Si el ID de rostro no es válido, la
implementación debe mostrar ILLEGAL_ARGUMENT |
getAuthenticatorId() |
Muestra un identificador asociado con el conjunto de rostros actual. Este identificador debe cambiar cada vez que se agrega un rostro. |
Diagrama de estado
El framework espera que faced siga el diagrama de estado que se muestra a continuación.
Figura 2: Flujo de estado de autenticación facial