Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Portero

El subsistema Gatekeeper realiza la autenticación de patrón / contraseña de dispositivo en un entorno de ejecución confiable (TEE). Gatekeeper registra y verifica las contraseñas a través de un HMAC con una clave secreta respaldada por hardware. Además, Gatekeeper acelera los intentos de verificación fallidos consecutivos y debe rechazar las solicitudes de servicio en función de un tiempo de espera determinado y una cantidad determinada de intentos fallidos consecutivos.

Cuando los usuarios verifican sus contraseñas, Gatekeeper utiliza el secreto compartido derivado de TEE para firmar una atestación de autenticación y enviarla al almacén de claves respaldado por hardware . Es decir, una certificación de Gatekeeper notifica a Keystore que las claves vinculadas a la autenticación (por ejemplo, las claves que las aplicaciones han creado) pueden liberarse para su uso por parte de las aplicaciones.

Arquitectura

Gatekeeper incluye tres componentes principales:

  • gatekeeperd (demonio Gatekeeper). Un servicio de enlace C ++ que contiene lógica independiente de la plataforma y que corresponde a la interfaz Java GateKeeperService .
  • Capa de abstracción de hardware de Gatekeeper (HAL) . La interfaz HAL en hardware/libhardware/include/hardware/gatekeeper.h el módulo de implementación.
  • Gatekeeper (TEE) . La contraparte TEE de gatekeeperd . Una implementación de Gatekeeper basada en TEE.

Gatekeeper requiere la implementación de Gatekeeper HAL (específicamente las funciones en hardware/libhardware/include/hardware/gatekeeper.h ) y el componente Gatekeeper específico de TEE (basado en parte en el archivo de encabezado system/gatekeeper/include/gatekeeper/gatekeeper.h que incluye funciones virtuales puras para crear / acceder a claves y firmas informáticas).

LockSettingsService realiza una solicitud (a través de Binder) que llega al demonio gatekeeperd en el sistema operativo Android. El demonio gatekeeperd luego realiza una solicitud que llega a su contraparte (Gatekeeper) en el TEE:

Flujo del portero
Figura 1. Flujo de datos de alto nivel para la autenticación por GateKeeper

El daemon gatekeeperd otorga a las API del marco de trabajo de Android acceso a HAL y participa en la notificación de autenticaciones de dispositivos al almacén de claves. El demonio gatekeeperd ejecuta en su propio proceso y está separado del servidor del sistema.

Implementación de HAL

El demonio gatekeeperd usa HAL para interactuar con la contraparte TEE del demonio gatekeeperd para la autenticación de contraseña. La implementación de HAL debe poder firmar (inscribir) y verificar blobs. Se espera que todas las implementaciones se adhieran al formato estándar para el token de autenticación (AuthToken) generado en cada verificación de contraseña exitosa. Para obtener detalles sobre el contenido y la semántica de AuthToken, consulte Formato de AuthToken .

Las implementaciones del archivo de encabezado hardware/libhardware/include/hardware/gatekeeper.h deben implementar las funciones de enroll y verify :

  • La función de enroll toma un blob de contraseña, lo firma y devuelve la firma como identificador. El blob devuelto (de una llamada para enroll ) debe tener la estructura que se muestra en system/gatekeeper/include/gatekeeper/password_handle.h .
  • La función de verify debe comparar la firma producida por la contraseña proporcionada y asegurarse de que coincida con el identificador de contraseña registrado.

La clave utilizada para inscribir y verificar nunca debe cambiar y debe ser re-derivable en cada arranque del dispositivo.

Trusty y otras implementaciones

El sistema operativo Trusty es el sistema operativo confiable de código abierto de Google para entornos TEE y contiene una implementación aprobada de GateKeeper. Sin embargo, puede utilizar cualquier sistema operativo TEE para implementar Gatekeeper siempre que el TEE tenga acceso a una clave respaldada por hardware y un reloj seguro y monótono que funcione en suspensión .

Trusty utiliza un sistema IPC interno para comunicar un secreto compartido directamente entre Keymaster y la implementación Trusty de Gatekeeper ( Trusty Gatekeeper ). Este secreto compartido se utiliza para firmar AuthTokens enviados a Keystore para proporcionar certificaciones de verificación de contraseña. Trusty Gatekeeper solicita la clave de Keymaster para cada uso y no persiste ni almacena en caché el valor. Las implementaciones son libres de compartir este secreto de cualquier forma que no comprometa la seguridad.

La clave HMAC utilizada para inscribir y verificar las contraseñas se deriva y se guarda únicamente en GateKeeper.

Android proporciona una implementación genérica de C ++ de GateKeeper que solo requiere la adición de rutinas específicas del dispositivo para completarse. Para implementar un TEE Gatekeeper con código específico del dispositivo para su TEE, consulte las funciones y comentarios en system/gatekeeper/include/gatekeeper/gatekeeper.h . Para TEE GateKeeper, las responsabilidades principales de una implementación compatible incluyen:

  • Adherencia al Gatekeeper HAL.
  • Los AuthTokens devueltos deben formatearse de acuerdo con la especificación AuthToken (descrita en Autenticación ).
  • El TEE Gatekeeper debe poder compartir una clave HMAC con Keymaster, ya sea solicitando la clave a través de un TEE IPC a pedido o manteniendo un caché válido del valor en todo momento.

Identificaciones seguras de usuario (SID)

Un SID de usuario es la representación TEE de un usuario (sin una conexión sólida con un ID de usuario de Android). El SID se genera con un generador de números pseudoaleatorios criptográficos (PRNG) cada vez que un usuario registra una nueva contraseña sin proporcionar una anterior. Esto se conoce como reinscripción no confiable y el marco de Android no lo permite en circunstancias normales. Una reinscripción confiable ocurre cuando un usuario proporciona una contraseña anterior válida; en este caso, el SID de usuario se migra al nuevo identificador de contraseña, conservando las claves que estaban vinculadas a él.

El SID de usuario se HMAC junto con la contraseña en el identificador de contraseña cuando se inscribe la contraseña.

Los SID de usuario se escriben en el AuthToken devuelto por la función de verify y se asocian a todas las claves del almacén de claves vinculadas a la autenticación (para obtener detalles sobre el formato AuthToken y el almacén de claves, consulte Autenticación ). Como una llamada no confiable a la función de enroll cambiará el SID del usuario, la llamada inutilizará las claves vinculadas a esa contraseña. Los atacantes pueden cambiar la contraseña del dispositivo si controlan el sistema operativo Android, pero destruirán las claves sensibles protegidas contra la raíz en el proceso.

Solicitar limitación

GateKeeper debe poder limitar de forma segura los intentos de fuerza bruta en una credencial de usuario. Como se muestra en hardware/libhardware/include/hardware/gatekeeper.h , HAL proporciona la devolución de un tiempo de espera en milisegundos. El tiempo de espera le informa al cliente que no vuelva a llamar a GateKeeper hasta que haya transcurrido el tiempo de espera; GateKeeper no debe atender solicitudes si hay un tiempo de espera pendiente.

GateKeeper debe escribir un contador de fallas antes de verificar una contraseña de usuario. Si la verificación de la contraseña tiene éxito, se debe borrar el contador de fallas. Esto evita los ataques que evitan el estrangulamiento al deshabilitar el MMC incorporado (eMMC) después de emitir una llamada de verify . La función de enroll también verifica la contraseña del usuario (si se proporciona) y debe regularse de la misma manera.

Si el dispositivo lo admite, se recomienda encarecidamente que el contador de fallas se escriba en un almacenamiento seguro. Si el dispositivo no admite el cifrado basado en archivos, o si el almacenamiento seguro es demasiado lento, las implementaciones pueden usar Replay Protected Memory Block (RPMB) directamente.