Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.
此页面由 Cloud Translation API 翻译。
Switch to English

Autenticación

Android usa el concepto de claves criptográficas de 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 almacén de claves respaldado por hardware y un 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. Dar fe de la presencia del usuario y / o autenticación exitosa. Android admite Gatekeeper para autenticación de PIN / patrón / contraseña y huella digital para autenticación de huellas digitales. Los dispositivos que se envían con Android 9 y BiometricPrompt posteriores 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 de almacén de claves de Android a nivel de marco también está respaldado por el servicio de almacén de claves).

Los componentes Gatekeeper, Fingerprint y Biometric 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 de enlace para el material criptográfico del usuario. Este SID de usuario está vinculado criptográficamente a la contraseña del usuario; Las autenticaciones exitosas para Gatekeeper dan como resultado AuthTokens que contienen el SID de usuario para esa contraseña.

Un usuario que desee cambiar una credencial debe presentar una credencial existente. Si una credencial existente se verifica con éxito, el SID del 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 del usuario anterior se pierden de forma permanente. Esto se conoce como inscripción no confiable .

En circunstancias normales, el marco 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, el restablecimiento forzoso de la contraseña, ya sea por parte de un administrador de dispositivo o un atacante, puede causar que esto ocurra.

Autenticación

Una vez que un usuario ha configurado una credencial y ha recibido un SID de usuario, puede iniciar la autenticación, que comienza cuando el 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 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 datos biométricos dependen de la versión de Android. En dispositivos con Android 8.xy versiones anteriores, FingerprintService realiza una solicitud a fingerprintd ). En los dispositivos que ejecutan Android 9 y superior, BiometricPrompt realiza una solicitud al demonio biométrico apropiado (por ejemplo, fingerprintd para huellas dactilares o faced para 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 asincrónica después de que se envía la solicitud.
  2. El daemon envía datos a su contraparte, que genera un AuthToken:
    • Para la autenticación de PIN / patrón / contraseña, gatekeeperd envía el PIN, patrón o hash de 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 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 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 el 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 AuthToken

Para garantizar el uso compartido 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 Necesario Descripción
Versión AuthToken 1 byte si 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 de cifrado solicitada. Actualmente utilizado por autorizaciones transaccionales de huellas dactilares. Si está presente, el AuthToken es válido solo para operaciones de cifrado que contienen el mismo desafío.
SID de usuario Entero sin signo de 64 bits si 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 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 si
  • 0x00 es Gatekeeper.
  • 0x01 es huella digital.
Marca de tiempo Entero sin signo de 64 bits en orden de red si Tiempo (en milisegundos) desde el inicio del sistema más reciente.
AuthToken HMAC (SHA-256) Blob de 256 bits si 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 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 característica de implementación dependiente de la plataforma. La llave nunca debe estar disponible fuera del TEE. Si un sistema operativo TEE carece de un mecanismo interno de comunicación entre procesos (IPC) y necesita transferir los datos a través del sistema operativo que no es de confianza, la transferencia debe realizarse mediante 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 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 almacén de claves rechace rápidamente las solicitudes que están destinadas a fallar, ya que tiene conocimiento de la tabla de autenticación en el sistema, ahorrando un IPC potencialmente costoso en el TEE.