Autenticación

Android utiliza el concepto de claves criptográficas activadas por autenticación de usuario que requiere los siguientes componentes:

  • Proveedor de servicios y almacenamiento de claves criptográficas. Almacena claves criptográficas y proporciona rutinas criptográficas estándar además de esas claves. Android admite Keystore y Keymaster respaldados por hardware para servicios criptográficos, incluida la criptografía respaldada por hardware para el almacenamiento de claves que puede incluir un entorno de ejecución confiable (TEE) o un elemento seguro (SE), como Strongbox.
  • Autenticadores de usuarios. Dar fe de la presencia del usuario y/o autenticación exitosa. Android es compatible con Gatekeeper para la autenticación de PIN/patrón/contraseña y Fingerprint para la autenticación de huellas dactilares. Los dispositivos que se envían con Android 9 y superior pueden usar BiometricPrompt como un único punto de integración para huellas dactilares y datos biométricos adicionales. Estos componentes comunican su estado de autenticación con el servicio de almacén de claves a través de un canal autenticado. (El sistema Android Keystore a nivel de marco también está respaldado por el servicio de almacenamiento de claves).

Los componentes Gatekeeper, Fingerprint y Biométrico funcionan con Keystore y otros componentes para admitir el uso de tokens de autenticación respaldados por hardware (AuthTokens).

Inscripción

En el primer arranque del dispositivo después de un restablecimiento de fábrica, todos los autenticadores están preparados para recibir inscripciones de credenciales del usuario. Un usuario debe registrar inicialmente un PIN/patrón/contraseña con Gatekeeper. Esta inscripción inicial crea un identificador seguro de usuario (SID) de 64 bits generado aleatoriamente que sirve como identificador para el usuario y como token vinculante para el material criptográfico del usuario. Este SID de usuario está vinculado criptográficamente a la contraseña del usuario; las autenticaciones exitosas en Gatekeeper dan como resultado AuthTokens que contienen el SID de usuario para esa contraseña.

Un usuario que quiera cambiar una credencial debe presentar una credencial existente. Si una credencial existente se verifica con éxito, el SID de usuario asociado con la credencial existente se transfiere a la nueva credencial, lo que permite al usuario seguir accediendo a las claves después de cambiar una credencial. Si un usuario no presenta una credencial existente, la nueva credencial se inscribe con un SID de usuario totalmente aleatorio. El usuario puede acceder al dispositivo, pero las claves creadas con el SID del usuario anterior se pierden de forma permanente. Esto se conoce como registro no confiable .

En circunstancias normales, el marco de trabajo de Android no permite una inscripción que no sea de confianza, por lo que la mayoría de los usuarios nunca verán esta funcionalidad. Sin embargo, los restablecimientos de contraseña forzados, ya sea por parte de un administrador de dispositivos o de un atacante, pueden hacer que esto ocurra.

Autenticación

Una vez que un usuario ha configurado una credencial y recibido un SID de usuario, puede iniciar la autenticación, que comienza cuando un usuario proporciona un PIN, un patrón, una contraseña o una huella digital. Todos los componentes de TEE comparten una clave secreta que utilizan para autenticar los mensajes de los demás.

Flujo de autenticación
Figura 1. Flujo de autenticación
  1. Un usuario proporciona un método de autenticación y el servicio asociado realiza una solicitud al demonio asociado.
    • Para PIN, patrón o contraseña, LockSettingsService realiza una solicitud a gatekeeperd .
    • Los flujos de autenticación basados ​​en biometría dependen de la versión de Android. En los dispositivos que ejecutan Android 8.x y versiones anteriores, FingerprintService realiza una solicitud de fingerprintd ). En los dispositivos que ejecutan Android 9 y versiones posteriores, BiometricPrompt realiza una solicitud al daemon biométrico apropiado (por ejemplo, fingerprintd por huellas digitales o faced por cara) utilizando la clase de Biometric Manager adecuada, como FingerprintManager o FaceManager . Independientemente de la versión, la autenticación biométrica se produce de forma asíncrona después de enviar la solicitud.
  2. El daemon envía datos a su contraparte, que genera un AuthToken:
    • Para la autenticación mediante PIN/patrón/contraseña, gatekeeperd envía el hash de PIN, patrón o contraseña a Gatekeeper en el TEE. Si la autenticación en el TEE es exitosa, Gatekeeper en el TEE envía un AuthToken que contiene el SID del usuario correspondiente (firmado con la clave AuthToken HMAC) a su contraparte en el sistema operativo Android.
    • Para la autenticación de huellas dactilares, fingerprintd escucha los eventos de huellas dactilares y envía los datos a Fingerprint en el TEE. Si la autenticación en el TEE es exitosa, Fingerprint en el TEE envía un AuthToken (firmado con la clave AuthToken HMAC) a su contraparte en el sistema operativo Android.
    • Para otras autenticaciones biométricas, el daemon biométrico apropiado escucha el evento biométrico y lo envía al componente TEE biométrico apropiado.
  3. El daemon recibe un AuthToken firmado y lo pasa al servicio de almacén de claves a través de una extensión a la interfaz Binder del servicio de almacén de claves. ( gatekeeperd también notifica al servicio de almacenamiento de claves cuando el dispositivo se vuelve a bloquear y cuando cambia la contraseña del dispositivo).
  4. El servicio de almacén de claves pasa los AuthTokens a Keymaster y los verifica utilizando la clave compartida con el Gatekeeper y el componente TEE biométrico compatible. Keymaster confía en la marca de tiempo en el token como la última hora de autenticación y basa una decisión de liberación de clave (para permitir que una aplicación use la clave) en la marca de tiempo.

Formato de token de autenticación

Para garantizar el intercambio de tokens y la compatibilidad entre idiomas y componentes, el formato de AuthToken se describe en hw_auth_token.h . El formato es un protocolo de serialización simple con campos de tamaño fijo.

Campo Escribe Requerido Descripción
Versión del token de autenticación 1 byte Sí Etiqueta de grupo para todos los campos a continuación.
Desafío Entero sin signo de 64 bits No Un número entero aleatorio para evitar ataques de repetición. Por lo general, el ID de una operación criptográfica solicitada. Actualmente utilizado por autorizaciones transaccionales de huellas dactilares. Si está presente, el AuthToken es válido solo para operaciones criptográficas que contengan el mismo desafío.
ID de usuario Entero sin signo de 64 bits Sí Identificador de usuario no repetitivo vinculado criptográficamente a todas las claves asociadas con la autenticación del dispositivo. Para obtener más información, consulte Gatekeeper .
ID del autenticador (ASID) Entero sin signo de 64 bits en orden de red No Identificador utilizado para enlazar con una política de autenticador específica. Todos los autenticadores tienen su propio valor de ASID que pueden cambiar según sus propios requisitos.
Tipo de autenticador Entero sin signo de 32 bits en orden de red Sí
  • 0x00 es portero.
  • 0x01 es huella digital.
marca de tiempo Entero sin signo de 64 bits en orden de red Sí Tiempo (en milisegundos) desde el arranque del sistema más reciente.
AuthToken HMAC (SHA-256) gota de 256 bits Sí SHA-256 MAC con clave de todos los campos excepto el campo HMAC.

Flujo de arranque del dispositivo

En cada arranque de un dispositivo, la clave HMAC de AuthToken debe generarse y compartirse con todos los componentes de TEE (Gatekeeper, Keymaster y trustlets biométricos compatibles). Por lo tanto, para mayor protección contra ataques de reproducción, la clave HMAC debe generarse aleatoriamente cada vez que se reinicia el dispositivo.

El protocolo para compartir esta clave HMAC con todos los componentes es una función de implementación que depende de la plataforma. La llave nunca debe estar disponible fuera del TEE. Si un sistema operativo TEE carece de un mecanismo de comunicación entre procesos internos (IPC) y necesita transferir los datos a través del sistema operativo que no es de confianza, la transferencia debe realizarse a través de un protocolo de intercambio de claves seguras.

El sistema operativo Trusty , que se ejecuta junto a Android, es un ejemplo de TEE, pero se pueden usar otros TEE en su lugar. Trusty utiliza un sistema IPC interno para comunicarse directamente entre Keymaster y Gatekeeper o el trustlet biométrico adecuado. La clave HMAC se mantiene únicamente en Keymaster; Fingerprint y Gatekeeper solicitan la clave de Keymaster para cada uso y no persisten ni almacenan en caché el valor.

Como algunos TEE carecen de una infraestructura IPC, no se produce comunicación entre los subprogramas en el TEE. Esto también permite que el servicio de almacenamiento de claves rechace rápidamente las solicitudes que seguramente fallarán, ya que tiene conocimiento de la tabla de autenticación en el sistema, ahorrando un IPC potencialmente costoso en el TEE.