Authentication

Android tiene el concepto de autenticadores de usuario que se usan para desbloquear el dispositivo y controlar el acceso a las claves criptográficas. Esto implica los siguientes componentes:

  • Proveedor de servicios y almacenamiento de claves criptográficas. Almacena claves criptográficas y proporciona rutinas criptográficas estándar sobre esas claves. Android admite un almacén de claves respaldado por hardware y KeyMint (anteriormente Keymaster) 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. Certificar la presencia del usuario o la autenticación exitosa Android admite Gatekeeper para la autenticación con PIN, patrón o contraseña, y Fingerprint para la autenticación con huella digital. Los dispositivos que se envían con Android 9 y versiones posteriores pueden usar BiometricPrompt como un único punto de integración para la huella dactilar y otros datos biométricos. 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 del framework también se basa en el servicio Keystore).

Cada uno de estos componentes es específico del proveedor, pero la implementación del proveedor debe satisfacer una especificación de interfaz de la capa de abstracción de hardware (HAL) y aprobar las pruebas correspondientes del conjunto de pruebas de proveedores (VTS).

Por lo general, las implementaciones del proveedor también se dividen en dos partes, conectadas por un mecanismo de comunicación específico del proveedor :

  • Un servicio HAL se ejecuta como un proceso del sistema Android y recibe solicitudes de Binder del sistema Android.
  • Una aplicación de confianza (TA) se ejecuta en el entorno seguro y realiza las operaciones seguras reales.

Inscripción

En el primer inicio del dispositivo después de un restablecimiento de la configuración de fábrica, todos los autenticadores se preparan para recibir inscripciones de credenciales del usuario. Inicialmente, el usuario debe inscribir un PIN, un patrón o una contraseña con Gatekeeper (o Weaver, si está disponible). Esta inscripción inicial crea un identificador seguro del usuario (SID) de 64 bits generado de forma aleatoria que sirve como identificador del usuario y como token de vinculación para el material criptográfico del usuario. Este SID del usuario está vinculado de forma criptográfica a la contraseña del usuario. Las autenticaciones exitosas en Gatekeeper generan AuthTokens que contienen el SID del usuario para esa contraseña.

Un usuario que quiera cambiar una credencial existente debe presentarla. Si se verifica correctamente una credencial existente, el SID del usuario asociado a la credencial existente se transfiere a la nueva, lo que permite que el usuario siga accediendo a las claves después de cambiar una credencial.

En algunas situaciones, un administrador del dispositivo puede realizar una inscripción no confiable para inscribir una nueva credencial sin presentar una existente. Esto permite que el usuario acceda al dispositivo, pero las claves creadas con el SID del usuario anterior se pierden de forma permanente.

Autenticación

En esta sección, se describe un flujo de autenticación típico, que implica interacciones entre varios componentes en Android y el entorno seguro. Ten en cuenta que todos los componentes seguros comparten una clave HMAC secreta (por inicio) que usan para autenticar los mensajes de los demás.

Después de que un usuario configura una credencial y se le asigna un SID de usuario, puede iniciar la autenticación, que comienza cuando el usuario proporciona un PIN, un patrón, una contraseña, una huella dactilar o algún otro dato biométrico sólido. 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 servicio HAL.
    • En el caso de PIN, patrón o contraseña, LockSettingsService realiza una solicitud a gatekeeperd.
    • Los flujos de autenticación basados en datos biométricos dependen de la versión de Android. En dispositivos que ejecutan Android 8.x y versiones anteriores, FingerprintService hace una solicitud a fingerprintd. En dispositivos que ejecutan Android 9 y versiones posteriores, BiometricPrompt hace una solicitud al daemon biométrico apropiado (por ejemplo, fingerprintd para huellas dactilares o faced para el rostro) con la clase BiometricManager apropiada, como FingerprintManager o FaceManager. Independientemente de la versión, la autenticación biométrica se produce de forma asíncrona después de que se envía la solicitud.
  2. El servicio de HAL envía datos a su TA correspondiente, que genera un AuthToken:
    • Para la autenticación con PIN, patrón o contraseña, gatekeeperd envía el hash del PIN, el patrón o la contraseña al TA de Gatekeeper en el TEE a través del servicio HAL de Gatekeeper. Si la autenticación en el TEE se realiza correctamente, la TA de Gatekeeper emite un AuthToken que contiene el SID del usuario correspondiente (firmado con la clave HMAC compartida).
    • Para la autenticación con huella digital, fingerprintd escucha los eventos de huella digital y envía los datos al TA de huella digital en el TEE a través de la HAL de huella digital. Si la autenticación en el TEE se realiza correctamente, el TA de Fingerprint emite un AuthToken (firmado con la clave HMAC de AuthToken).
    • Para otra autenticación biométrica, el daemon biométrico adecuado escucha el evento biométrico y lo envía al servicio de HAL biométrico y al TA adecuados.
  3. El daemon recibe un AuthToken firmado y lo pasa al servicio de almacén de claves a través de una extensión de la interfaz de Binder del servicio de almacén de claves. (gatekeeperd también notifica al servicio de almacén de claves cuando se vuelve a bloquear el dispositivo y cuando cambia la contraseña del dispositivo).
  4. El servicio de Keystore pasa los AuthTokens a KeyMint y los verifica con la clave compartida con Gatekeeper y el componente de TEE biométrico compatible. KeyMint 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 claves (para permitir que una app use la clave) en la marca de tiempo.

El flujo de autenticación no requiere comunicación directa entre las A.T. en el entorno seguro: los AuthTokens fluyen desde la A.T. del autenticador al servicio keystore2 en Android, que a su vez los pasa a la A.T. de KeyMint. Esto también permite que el servicio keystore2 rechace rápidamente las solicitudes que seguramente fallarán, ya que conoce los AuthTokens disponibles en el sistema, lo que ahorra un IPC potencialmente costoso en el TEE.

Formato de AuthToken

El formato de AuthToken se proporciona en la especificación de AIDL en HardwareAuthToken.aidl.

Flujo de inicio del dispositivo

En cada inicio de un dispositivo, se debe generar la clave HMAC de AuthToken y compartirla con todos los componentes del TEE (Gatekeeper, KeyMint y los trustlets biométricos compatibles). Por lo tanto, para mayor protección contra ataques de reproducción, la clave HMAC se debe generar de forma aleatoria cada vez que se reinicia el dispositivo.

Existen dos formas comunes en que los TA adquieren acceso a esta clave HMAC compartida:

  • Acuerdo de secreto compartido: El servicio keystore2 realiza un protocolo de acuerdo de claves multidireccional en el inicio del dispositivo, lo que permite la derivación segura de la clave HMAC entre las TA que participan. Sin embargo, los TA participantes deben tener acceso a un secreto compartido previo común.
  • Acceso directo: Las TA que residen en el mismo entorno seguro pueden usar un mecanismo interno de comunicación entre procesos (que depende de la plataforma) para compartir la clave HMAC.

En cualquier caso, la clave HMAC nunca debe estar disponible fuera del TEE.

El sistema operativo Trusty, que se ejecuta junto con Android, es un ejemplo de un TEE, pero se pueden usar otros TEE en su lugar. Trusty usa un sistema IPC interno para comunicarse directamente entre KeyMint y Gatekeeper, o la trustlet biométrica adecuada. La clave HMAC se mantiene solo en KeyMint. Fingerprint y Gatekeeper solicitan la clave a KeyMint para cada uso y no conservan ni almacenan en caché el valor.

Como algunos TEE no tienen una infraestructura de IPC, no se produce comunicación entre los applets en el TEE. Esto también permite que el servicio de almacén de claves rechace rápidamente las solicitudes que seguramente fallarán, ya que conoce la tabla de autenticación del sistema, lo que ahorra un IPC potencialmente costoso en el TEE.