Authentication

Android tiene el concepto de autenticadores de usuarios 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. Android Keystore proporciona servicios criptográficos respaldados por hardware para las apps. El sistema de Android Keystore a nivel del framework está respaldado por el servicio del sistema keystore2. Esto se basa, a su vez, en una implementación subyacente de KeyMint (anteriormente Keymaster) específica del proveedor que garantiza que solo se pueda acceder al material de claves en un entorno seguro respaldado por hardware, como un entorno de ejecución confiable (TEE) o un elemento seguro (SE), como StrongBox.
  • Autenticadores de usuarios. Certificar la autenticación correcta del usuario Android admite los siguientes componentes de autenticación:
    • Gatekeeper para la autenticación con PIN, patrón o contraseña en el TEE
    • (Opcional) Weaver para la autenticación con PIN, patrón o contraseña en un elemento seguro
    • Huella dactilar para la autenticación con huella dactilar
    • Otros métodos de autenticación biométrica Los dispositivos que se envían con Android 9 o versiones posteriores pueden usar BiometricPrompt como un punto de integración único para la huella dactilar y otros datos biométricos.
    Estos componentes comunican su estado de autenticación con el servicio keystore2 a través del uso de tokens de autenticación (AuthTokens) respaldados por hardware.

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

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

  • Un servicio de 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 de seguridad reales.

Inscripción

En el primer inicio del dispositivo después de un restablecimiento de la configuración de fábrica, todos los autenticadores están preparados 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 de usuario (SID) de 64 bits generado de forma aleatoria que sirve como identificador para el usuario y como token de vinculación para el material criptográfico del usuario. Este SID de usuario está vinculado de forma criptográfica a la contraseña del usuario. Las autenticaciones exitosas en Gatekeeper generan AuthTokens que contienen el SID de usuario para esa contraseña.

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

En algunas situaciones, un administrador de dispositivos puede realizar una inscripción no confiable para inscribir una credencial nueva sin presentar una credencial 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, tanto en Android como en 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 de HAL.
    • Para el PIN, el patrón o la 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 los dispositivos que ejecutan Android 8.x y versiones anteriores, FingerprintService realiza una solicitud a fingerprintd). En los dispositivos que ejecutan Android 9 y versiones posteriores, BiometricPrompt realiza una solicitud al daemon biométrico correspondiente (por ejemplo, fingerprintd para huellas dactilares o faced para rostros) con la clase BiometricManager adecuada, 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 equivalente, 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 de 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 de huellas digitales, fingerprintd escucha los eventos de huellas digitales y envía los datos a la TA de huellas digitales en el TEE, a través de la HAL de huellas digitales. Si la autenticación en el TEE se realiza correctamente, la TA de huellas dactilares 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 a la TA correspondientes.
  3. El AuthToken firmado resultante se pasa al servicio del sistema keystore2 a través de una interfaz de Binder.
  4. El servicio keystore2 adjunta los AuthTokens a la solicitud para que KeyMint (anteriormente Keymaster) realice operaciones criptográficas. El servicio de HAL de KeyMint los pasa a la TA de KeyMint, que los verifica con la clave HMAC compartida con Gatekeeper y los componentes de TEE biométricos compatibles. KeyMint confía en la marca de tiempo del token como la última hora de autenticación y decide si permite el uso de la clave en función de la marca de tiempo.

El flujo de autenticación no requiere comunicación directa entre las TA en el entorno seguro: los AuthTokens fluyen de la TA del autenticador al servicio keystore2 en Android, que, a su vez, los pasa a la TA de KeyMint. Esto también permite que el servicio keystore2 rechace con rapidez las solicitudes que están destinadas a fallar, ya que tiene conocimiento de los AuthTokens disponibles en el sistema, lo que ahorra una IPC potencialmente costosa en el TEE.

Formato de AuthToken

El formato del AuthToken se indica 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 de TEE (Gatekeeper, KeyMint y TA biométricas compatibles). Para evitar 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 las que las TA adquieren acceso a esta clave HMAC compartida:

  • Acuerdo de secreto compartido: El servicio keystore2 realiza un protocolo de acuerdo de claves de varias vías en el inicio del dispositivo, lo que permite la derivación segura de la clave HMAC entre las TA que participan. Sin embargo, las TA participantes deben tener acceso a un secreto compartido común.
  • Acceso directo: Las TA que residen en el mismo entorno seguro pueden usar un mecanismo de comunicación entre procesos interno (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 TEE, pero se pueden usar otros TEE en su lugar. Trusty usa un sistema de IPC interno para comunicarse directamente entre KeyMint y Gatekeeper o la TA biométrica adecuada. La clave HMAC se mantiene únicamente 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 carecen de 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 fallarán, ya que tiene conocimiento de la tabla de autenticación en el sistema, lo que ahorra una IPC potencialmente costosa en el TEE.