Weaver

La capa de abstracción de hardware (HAL) de Weaver (IWeaver.aidl), que se introdujo en Android 8.1, proporciona una interfaz segura para la autenticación del usuario con el factor de conocimiento de la pantalla de bloqueo (LSKF), como el PIN, el patrón y la contraseña.

Weaver reemplaza la funcionalidad de verificación de LSKF de Gatekeeper. Sin embargo, Gatekeeper se sigue usando para generar tokens de autenticación de hardware.

En Android 9 y versiones posteriores, el CDD 9.11.2 requiere que los dispositivos que admiten StrongBox proporcionen hardware seguro dedicado que respalde la autenticación segura del usuario. La implementación del HAL de Weaver con este hardware seguro satisface el requisito de "autenticación segura del usuario".

En los dispositivos sin un elemento seguro (SE) dedicado, Weaver se puede implementar en un entorno de ejecución confiable (TEE) como Trusty.

En Android 17 y versiones posteriores, se recomienda implementar Weaver incluso en dispositivos sin un elemento seguro dedicado.

Componentes

Weaver consta de tres componentes:

  • Interfaz de AIDL de Weaver (IWeaver): Es la especificación formal de la HAL. Android 13 y versiones anteriores usaban HIDL en lugar de AIDL.
  • Servicio de capa de abstracción de hardware (HAL) de Weaver: Es un proceso de Android específico del proveedor que implementa la interfaz IWeaver.
  • Aplicación de confianza de Weaver (TA): Es la lógica principal que se ejecuta en un entorno seguro. Realiza la verificación de LSKF y aplica la limitación de frecuencia. El servicio de HAL se comunica con el TA a través de un canal seguro específico de la implementación.

Interfaz

La interfaz de Weaver presenta un array de tamaño fijo de ranuras persistentes, cada una de las cuales contiene una clave y un valor de tamaño fijo. Cada ranura se identifica por su ID, un número entero en el intervalo [0, numSlots - 1]. El valor de una ranura solo es accesible cuando se proporciona una clave que coincide con la clave almacenada.

La interfaz de Weaver consta principalmente de los siguientes elementos:

  • getConfig(): Recupera la cantidad de ranuras, el tamaño de la clave y el tamaño del valor que admite la implementación.
  • write(): Sobrescribe la ranura especificada con un nuevo par clave-valor. Esta operación es atómica y hace que los datos anteriores sean irrecuperables de forma permanente (eliminación segura).
  • read(): Intenta recuperar el valor de la ranura especificada. Esta operación solo se realiza correctamente cuando el tiempo de espera de limitación de frecuencia (aplicado por la TA) no está activo y la clave proporcionada coincide exactamente con la clave almacenada.
  • warmUp(): En Android 17 y versiones posteriores, transmite una sugerencia de que podría ocurrir una lectura o escritura pronto.

Para ver la especificación completa de la interfaz, consulta IWeaver.aidl.

Uso por parte de Android

Cuando hay una implementación de Weaver disponible, LockSettingsService en el servidor del sistema Android la usa para proteger los datos del usuario. Para cada usuario del dispositivo, LockSettingsService administra una ranura de Weaver:

  • Clave de ranura (weaverKey): Es un hash de la LSKF del usuario. Si el usuario no tiene un bloqueo de pantalla, se usa una cadena predeterminada.
  • Valor de ranura (weaverSecret): Es un secreto criptográfico de alta entropía generado de forma aleatoria.

El weaverSecret está diseñado para recuperarse solo de una de las siguientes maneras:

  • Proporcionar el weaverKey correcto al TA de Weaver dentro de su política de limitación de frecuencia
  • Comprometer el entorno seguro en el que se ejecuta el TA de Weaver Esto está diseñado para ser muy difícil.

LockSettingsService usa weaverKey y weaverSecret para encriptar la contraseña sintética del usuario. Dado que la contraseña sintética protege el almacenamiento encriptado con credenciales (CE) del usuario para la encriptación basada en archivos (FBE) y las claves vinculadas a la autenticación del usuario en Android Keystore, los datos permanecen inaccesibles hasta que Weaver divulga el secreto.

En Android 17 y versiones posteriores, LockSettingsService llama al método warmUp() de Weaver cuando se comienza a ingresar la LSKF. Las implementaciones de Weaver pueden usar este indicador para sacar el hardware seguro de un estado de bajo consumo y reducir la latencia de una próxima solicitud de read().

Weaver en comparación con Gatekeeper

Históricamente, el HAL de Gatekeeper desempeñaba dos roles distintos en una sola llamada a verify():

  1. Verificación: Comprobación de la LSKF, con limitación de frecuencia aplicada por el TEE.
  2. Certificación: Emite un HardwareAuthToken para notificar a KeyMint (anteriormente Keymaster) que la autenticación de LSKF se realizó correctamente.

¿Por qué cambiamos a Weaver?

Con la introducción de los tokens de restablecimiento seguro de contraseñas en Android 8.1, la contraseña sintética se convirtió en el secreto criptográfico principal. Los dos roles descritos anteriormente se controlan con inscripciones separadas de Gatekeeper, una para la LSKF en userId + 100000 y otra para la contraseña sintética en userId.

Se introdujo Weaver para asumir el primer rol, con una interfaz HAL más simple que admite implementaciones basadas en el elemento seguro (SE).

Función Weaver Gatekeeper
Eliminación segura Se requiere un borrado seguro, y es fácil de implementar porque la interfaz usa una cantidad fija de ranuras de tamaño fijo. No se requiere el borrado seguro y es difícil implementarlo porque la interfaz admite una cantidad ilimitada de inscripciones.
Hardware Está optimizado para los SE, pero también funciona en los TEE. Es solo para TEE de manera efectiva. Implementarlo en un SE no proporciona un beneficio de seguridad con el diseño actual.
Manejo de errores Códigos de error más claros Códigos de error ambiguos. Como resultado, la pantalla de bloqueo no diferencia entre las LSKF incorrectas y las fallas no relacionadas.
Atomicidad El código en LockSettingsService que usa Weaver realiza cambios en LSKF de forma atómica. Los datos nuevos se escriben en una nueva ranura de Weaver, y la ranura anterior se borra solo cuando es seguro hacerlo. El código de LockSettingsService que usa Gatekeeper no realiza cambios en LSKF de forma atómica. Si algo sale mal durante el cambio de la LSKF, es posible que se pierdan todos los datos del usuario.

Código de referencia

El AOSP contiene dos implementaciones de referencia de Weaver:

  • En Android 17 y versiones posteriores, system/weaver/ contiene una implementación de Weaver para entornos seguros generales.
  • En Android 8.1 y versiones posteriores, external/libese/ contiene una implementación de Weaver para elementos seguros compatibles con ISO/IEC7816-4.

Prueba

Para validar una implementación de Weaver, usa VtsHalWeaverTargetTest: 

atest VtsHalWeaverTargetTest

o:

vts-tradefed run vts -m VtsHalWeaverTargetTest