Autenticación

Android utiliza el concepto de claves criptográficas controladas 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 un 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 de la autenticación exitosa. Android admite Gatekeeper para autenticación de PIN/patrón/contraseña y Fingerprint para 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 almacén 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 inicio del dispositivo después de un restablecimiento de fábrica, todos los autenticadores están preparados para recibir inscripciones de credenciales del usuario. Inicialmente, un usuario debe registrar 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 exitosamente, 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 completamente aleatorio. El usuario puede acceder al dispositivo, pero las claves creadas con el SID de usuario anterior se pierden permanentemente. Esto se conoce como inscripción 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 forzosos de contraseña, ya sea por parte de un administrador del dispositivo o de un atacante, pueden provocar que esto ocurra.

Autenticación

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

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 dispositivos con Android 8.x y versiones anteriores, FingerprintService realiza una solicitud a fingerprintd ). En dispositivos con Android 9 y versiones posteriores, BiometricPrompt realiza una solicitud al demonio biométrico apropiado (por ejemplo, fingerprintd para huellas dactilares o faced para rostro) utilizando la clase Biometric Manager apropiado, como FingerprintManager o FaceManager . Independientemente de la versión, la autenticación biométrica se produce de forma asincrónica después de enviar la solicitud.
  2. El demonio envía datos a su contraparte, que genera un AuthToken:
    • Para la autenticación de 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 de 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 otra autenticación biométrica, el demonio biométrico apropiado escucha el evento biométrico y lo envía al componente TEE biométrico apropiado.
  3. El demonio recibe un AuthToken firmado y lo pasa al servicio de almacén de claves a través de una extensión de la interfaz Binder del servicio de almacén de claves. ( gatekeeperd también notifica al servicio de almacén 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 Gatekeeper y el componente TEE biométrico compatible. Keymaster confía en la marca de tiempo del 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 AuthToken se describe en hw_auth_token.h . El formato es un protocolo de serialización simple con campos de tamaño fijo.

Campo Tipo Requerido Descripción
Versión de 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. Generalmente, 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 Guardián .
ID de autenticador (ASID) Entero sin signo de 64 bits en orden de red No Identificador utilizado para vincularse a una política de autenticación 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 el guardián.
  • 0x01 es huella digital.
Marca de tiempo Entero sin signo de 64 bits en orden de red Sí Tiempo (en milisegundos) desde el inicio más reciente del sistema.
AuthToken HMAC (SHA-256) blob de 256 bits Sí MAC SHA-256 con clave de todos los campos excepto el campo HMAC.

Flujo de arranque del dispositivo

En cada arranque de un dispositivo, la clave AuthToken HMAC 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 repetició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 característica de implementación que depende de la plataforma. La clave nunca debe estar disponible fuera del TEE. Si un TEE OS carece de un mecanismo interno de comunicación entre procesos (IPC) y necesita transferir los datos a través de un sistema operativo que no es de confianza, la transferencia debe realizarse a través de un protocolo de intercambio de claves seguro.

El sistema operativo Trusty , que se ejecuta junto a Android, es un ejemplo de TEE, pero en su lugar se pueden utilizar otros TEE. Trusty utiliza un sistema IPC interno para comunicarse directamente entre Keymaster y Gatekeeper o el trustlet biométrico apropiado. La clave HMAC se guarda únicamente en Keymaster; Fingerprint y Gatekeeper solicitan la clave a Keymaster para cada uso y no conservan 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 almacén de claves rechace rápidamente 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.