A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.

Se usó la API de Cloud Translation para traducir esta página.

HIDL de autenticación facial

Descripción general

La autenticación facial permite a los usuarios desbloquear el dispositivo con solo mirar la parte frontal. Android 10 agrega compatibilidad con 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, como la banca en línea o cualquier otro servicio.

La pila de autenticación facial de Android es una nueva implementación en Android 10. La nueva implementación introduce las interfaces IBiometricsFace.hal, IBiometricsFaceClientCallback.hal y types.hal.

Arquitectura

La API de BiometricPrompt incluye toda la autenticación biométrica, como la facial, la de huella dactilar y la de iris. El HAL de Face interactúa con los siguientes componentes.

FaceManager

FaceManager es una interfaz privada que mantiene una conexión con FaceService. Keyguard lo 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 que se ejecute ningún 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.

enfrentó

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 Face, 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 estados al estado inactivo después de que se envían. La mayoría de los mensajes tienen una cadena correspondiente para el usuario que le informa 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 el registro o la autenticación, y tienen como objetivo guiar al usuario hacia un registro o una autenticación exitosos. Cada ordinal tiene un mensaje asociado del archivo FaceAuthenticationManager.java. 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 sean necesarios para completar la inscripción o autenticación actual. Si un mensaje de adquisición genera un estado final 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 demasiado oscura para que se pueda avanzar. En este caso, es razonable enviar UNABLE_TO_PROCESS después de varios intentos sin lograr ningún avance.

Hardware

Para que los dispositivos cumplan con los requisitos de biometría avanzada de Android 10, deben tener hardware seguro para garantizar la integridad de los datos faciales y la comparación final de la autenticación. En el Documento de Definición de Compatibilidad de Android (CDD), se describe el nivel de seguridad requerido y el porcentaje de aceptación de suplantació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 imágenes podrían ser privilegiadas y estar marcadas como de solo lectura para que solo el hardware de la cámara pueda actualizarlas. Idealmente, ningún proceso debería tener 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 siguientes métodos son asíncronos y deben regresar de inmediato al framework. De lo contrario, el sistema será lento y es posible que se restablezca el Watchdog. Se recomienda tener una cola de mensajes con varios subprocesos para evitar bloquear al llamador. Todas las solicitudes GET deben almacenar en caché la información siempre que sea posible para que el llamador se bloquee durante un período mínimo.

Método	Descripción
`setCallback()`	`FaceService` llama a esta función para canalizar todos los mensajes de vuelta a sí misma.
`setActiveUser()`	Establece el usuario activo al que se aplican todas las operaciones posteriores del HAL. La autenticación siempre es para este usuario hasta que se vuelva 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, inscripción, autenticación, eliminación o enumeración) y devuelve `faced` al estado inactivo.
`enumerate()`	Enumera todas las plantillas de rostro 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 se debe usar cuando el HAL está en estado de autenticación o en espera. Si se usa este método cuando el HAL no está en uno de estos estados, se devuelve `OPERATION_NOT_SUPPORTED`. Llamar a este método mientras el HAL ya está autenticando puede extender la cantidad de tiempo que el sistema busca un rostro.
`resetLockout()`	Cuando se rechazan demasiados rostros, se requiere `faced` para ingresar a un estado de bloqueo (`LOCKOUT` o `LOCKOUT_PERMANENT`). Cuando lo hace, se requiere 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 menor tiempo posible para evitar que el framework se detenga.

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, esto requiere un HAT para verificar el PIN, el patrón o la contraseña del usuario en relación con el desafío anterior.
`getFeature()`	Recupera el estado de habilitación actual de la función, según lo indica el valor predeterminado o una llamada a `setFeature()` anterior. Si el ID de rostro no es válido, la implementación debe devolver `ILLEGAL_ARGUMENT`.
`getAuthenticatorId()`	Devuelve un identificador asociado con el conjunto de rostros actual. Este identificador debe cambiar cada vez que se agregue un rostro.

Diagrama de estado

El framework espera que faced siga el siguiente diagrama de estado.